LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* linux-next: build warnings after merge of the tip tree
@ 2011-01-31  4:27 Stephen Rothwell
  2011-01-31  5:08 ` Jaswinder Singh
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2011-01-31  4:27 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Venkatesh Pallipadi

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

kernel/sched.c:3719: warning: 'irqtime_account_idle_ticks' defined but not used
kernel/sched.c:3720: warning: 'irqtime_account_process_tick' defined but not used

Introduced by commit abb74cefa9c682fb38ba86c17ca3c86fed6cc464 ("sched:
Export ns irqtimes through /proc/stat").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2011-01-31  4:27 linux-next: build warnings after merge of the tip tree Stephen Rothwell
@ 2011-01-31  5:08 ` Jaswinder Singh
  2011-01-31 19:12   ` [PATCH] Fix linux-next warning from abb74cef Venkatesh Pallipadi
  0 siblings, 1 reply; 89+ messages in thread
From: Jaswinder Singh @ 2011-01-31  5:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Venkatesh Pallipadi

Hello,

On Mon, Jan 31, 2011 at 9:57 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
>
> kernel/sched.c:3719: warning: 'irqtime_account_idle_ticks' defined but not used
> kernel/sched.c:3720: warning: 'irqtime_account_process_tick' defined but not used
>

These functions should move inside ifndef CONFIG_VIRT_CPU_ACCOUNTING

Thanks,
--
Jaswinder Singh.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* [PATCH] Fix linux-next warning from abb74cef
  2011-01-31  5:08 ` Jaswinder Singh
@ 2011-01-31 19:12   ` Venkatesh Pallipadi
  2011-01-31 19:38     ` Randy Dunlap
  0 siblings, 1 reply; 89+ messages in thread
From: Venkatesh Pallipadi @ 2011-01-31 19:12 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	linux-kernel, Stephen Rothwell, Jaswinder Singh,
	Venkatesh Pallipadi

Yes. Patch below should fix the problem.

Fix below warning -
 Introduced by commit abb74cefa9c682fb38ba86c17ca3c86fed6cc464 ("sched:
 Export ns irqtimes through /proc/stat").

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

kernel/sched.c:3719: warning: 'irqtime_account_idle_ticks' defined but not =
used
kernel/sched.c:3720: warning: 'irqtime_account_process_tick' defined but no=
t used

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
---
 kernel/sched.c |   64 ++++++++++++++++++++++++++++----------------------------
 1 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 477e1bc..9a552bd 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3654,6 +3654,36 @@ void account_system_time(struct task_struct *p, int hardirq_offset,
 	__account_system_time(p, cputime, cputime_scaled, target_cputime64);
 }
 
+/*
+ * Account for involuntary wait time.
+ * @steal: the cpu time spent in involuntary wait
+ */
+void account_steal_time(cputime_t cputime)
+{
+	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
+	cputime64_t cputime64 = cputime_to_cputime64(cputime);
+
+	cpustat->steal = cputime64_add(cpustat->steal, cputime64);
+}
+
+/*
+ * Account for idle time.
+ * @cputime: the cpu time spent in idle wait
+ */
+void account_idle_time(cputime_t cputime)
+{
+	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
+	cputime64_t cputime64 = cputime_to_cputime64(cputime);
+	struct rq *rq = this_rq();
+
+	if (atomic_read(&rq->nr_iowait) > 0)
+		cpustat->iowait = cputime64_add(cpustat->iowait, cputime64);
+	else
+		cpustat->idle = cputime64_add(cpustat->idle, cputime64);
+}
+
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING
+
 #ifdef CONFIG_IRQ_TIME_ACCOUNTING
 /*
  * Account a tick to a process and cpustat
@@ -3715,41 +3745,11 @@ static void irqtime_account_idle_ticks(int ticks)
 	for (i = 0; i < ticks; i++)
 		irqtime_account_process_tick(current, 0, rq);
 }
-#else
+#else /* CONFIG_IRQ_TIME_ACCOUNTING */
 static void irqtime_account_idle_ticks(int ticks) {}
 static void irqtime_account_process_tick(struct task_struct *p, int user_tick,
 						struct rq *rq) {}
-#endif
-
-/*
- * Account for involuntary wait time.
- * @steal: the cpu time spent in involuntary wait
- */
-void account_steal_time(cputime_t cputime)
-{
-	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
-	cputime64_t cputime64 = cputime_to_cputime64(cputime);
-
-	cpustat->steal = cputime64_add(cpustat->steal, cputime64);
-}
-
-/*
- * Account for idle time.
- * @cputime: the cpu time spent in idle wait
- */
-void account_idle_time(cputime_t cputime)
-{
-	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
-	cputime64_t cputime64 = cputime_to_cputime64(cputime);
-	struct rq *rq = this_rq();
-
-	if (atomic_read(&rq->nr_iowait) > 0)
-		cpustat->iowait = cputime64_add(cpustat->iowait, cputime64);
-	else
-		cpustat->idle = cputime64_add(cpustat->idle, cputime64);
-}
-
-#ifndef CONFIG_VIRT_CPU_ACCOUNTING
+#endif /* CONFIG_IRQ_TIME_ACCOUNTING */
 
 /*
  * Account a single tick of cpu time.
-- 
1.7.3.1


^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: [PATCH] Fix linux-next warning from abb74cef
  2011-01-31 19:12   ` [PATCH] Fix linux-next warning from abb74cef Venkatesh Pallipadi
@ 2011-01-31 19:38     ` Randy Dunlap
  2011-01-31 20:16       ` Venkatesh Pallipadi
  0 siblings, 1 reply; 89+ messages in thread
From: Randy Dunlap @ 2011-01-31 19:38 UTC (permalink / raw)
  To: Venkatesh Pallipadi
  Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel, Stephen Rothwell, Jaswinder Singh

On Mon, 31 Jan 2011 11:12:43 -0800 Venkatesh Pallipadi wrote:

> Yes. Patch below should fix the problem.
> 
> Fix below warning -
>  Introduced by commit abb74cefa9c682fb38ba86c17ca3c86fed6cc464 ("sched:
>  Export ns irqtimes through /proc/stat").
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
> 
> kernel/sched.c:3719: warning: 'irqtime_account_idle_ticks' defined but not =
> used
> kernel/sched.c:3720: warning: 'irqtime_account_process_tick' defined but no=
> t used

[ugh on the '=' line continuations.]

> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Venkatesh Pallipadi <venki@google.com>
> ---
>  kernel/sched.c |   64 ++++++++++++++++++++++++++++----------------------------
>  1 files changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/kernel/sched.c b/kernel/sched.c
> index 477e1bc..9a552bd 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -3654,6 +3654,36 @@ void account_system_time(struct task_struct *p, int hardirq_offset,
>  	__account_system_time(p, cputime, cputime_scaled, target_cputime64);
>  }
>  
> +/*
> + * Account for involuntary wait time.
> + * @steal: the cpu time spent in involuntary wait

I see that you only moved this code, but please change @steal to @cputime also.

> + */
> +void account_steal_time(cputime_t cputime)
> +{
> +	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
> +	cputime64_t cputime64 = cputime_to_cputime64(cputime);
> +
> +	cpustat->steal = cputime64_add(cpustat->steal, cputime64);
> +}

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: [PATCH] Fix linux-next warning from abb74cef
  2011-01-31 19:38     ` Randy Dunlap
@ 2011-01-31 20:16       ` Venkatesh Pallipadi
  2011-01-31 20:25         ` Randy Dunlap
  0 siblings, 1 reply; 89+ messages in thread
From: Venkatesh Pallipadi @ 2011-01-31 20:16 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	linux-kernel, Stephen Rothwell, Jaswinder Singh, Randy Dunlap,
	Venkatesh Pallipadi

Thanks. Updated to address comments from Randy.

Yes. Patch below should fix the problem.

Fix below warning -
 Introduced by commit abb74cefa9c682fb38ba86c17ca3c86fed6cc464 ("sched:
 Export ns irqtimes through /proc/stat").

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

kernel/sched.c:3719: warning: 'irqtime_account_idle_ticks' defined but not used
kernel/sched.c:3720: warning: 'irqtime_account_process_tick' defined but not used

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
---
 kernel/sched.c |   64 ++++++++++++++++++++++++++++----------------------------
 1 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 477e1bc..9a552bd 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3654,6 +3654,36 @@ void account_system_time(struct task_struct *p, int hardirq_offset,
 	__account_system_time(p, cputime, cputime_scaled, target_cputime64);
 }
 
+/*
+ * Account for involuntary wait time.
+ * @cputime: the cpu time spent in involuntary wait
+ */
+void account_steal_time(cputime_t cputime)
+{
+	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
+	cputime64_t cputime64 = cputime_to_cputime64(cputime);
+
+	cpustat->steal = cputime64_add(cpustat->steal, cputime64);
+}
+
+/*
+ * Account for idle time.
+ * @cputime: the cpu time spent in idle wait
+ */
+void account_idle_time(cputime_t cputime)
+{
+	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
+	cputime64_t cputime64 = cputime_to_cputime64(cputime);
+	struct rq *rq = this_rq();
+
+	if (atomic_read(&rq->nr_iowait) > 0)
+		cpustat->iowait = cputime64_add(cpustat->iowait, cputime64);
+	else
+		cpustat->idle = cputime64_add(cpustat->idle, cputime64);
+}
+
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING
+
 #ifdef CONFIG_IRQ_TIME_ACCOUNTING
 /*
  * Account a tick to a process and cpustat
@@ -3715,41 +3745,11 @@ static void irqtime_account_idle_ticks(int ticks)
 	for (i = 0; i < ticks; i++)
 		irqtime_account_process_tick(current, 0, rq);
 }
-#else
+#else /* CONFIG_IRQ_TIME_ACCOUNTING */
 static void irqtime_account_idle_ticks(int ticks) {}
 static void irqtime_account_process_tick(struct task_struct *p, int user_tick,
 						struct rq *rq) {}
-#endif
-
-/*
- * Account for involuntary wait time.
- * @steal: the cpu time spent in involuntary wait
- */
-void account_steal_time(cputime_t cputime)
-{
-	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
-	cputime64_t cputime64 = cputime_to_cputime64(cputime);
-
-	cpustat->steal = cputime64_add(cpustat->steal, cputime64);
-}
-
-/*
- * Account for idle time.
- * @cputime: the cpu time spent in idle wait
- */
-void account_idle_time(cputime_t cputime)
-{
-	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
-	cputime64_t cputime64 = cputime_to_cputime64(cputime);
-	struct rq *rq = this_rq();
-
-	if (atomic_read(&rq->nr_iowait) > 0)
-		cpustat->iowait = cputime64_add(cpustat->iowait, cputime64);
-	else
-		cpustat->idle = cputime64_add(cpustat->idle, cputime64);
-}
-
-#ifndef CONFIG_VIRT_CPU_ACCOUNTING
+#endif /* CONFIG_IRQ_TIME_ACCOUNTING */
 
 /*
  * Account a single tick of cpu time.
-- 
1.7.3.1


^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: [PATCH] Fix linux-next warning from abb74cef
  2011-01-31 20:16       ` Venkatesh Pallipadi
@ 2011-01-31 20:25         ` Randy Dunlap
  0 siblings, 0 replies; 89+ messages in thread
From: Randy Dunlap @ 2011-01-31 20:25 UTC (permalink / raw)
  To: Venkatesh Pallipadi
  Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel, Stephen Rothwell, Jaswinder Singh,
	Randy Dunlap

On Mon, 31 Jan 2011 12:16:46 -0800 Venkatesh Pallipadi wrote:

> Thanks. Updated to address comments from Randy.
> 
> Yes. Patch below should fix the problem.
> 
> Fix below warning -
>  Introduced by commit abb74cefa9c682fb38ba86c17ca3c86fed6cc464 ("sched:
>  Export ns irqtimes through /proc/stat").

Thanks, Venki.

Maybe next time we can even get a descriptive $subject.  ;)
(I'm not requesting that you resend this patch.)


> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
> 
> kernel/sched.c:3719: warning: 'irqtime_account_idle_ticks' defined but not used
> kernel/sched.c:3720: warning: 'irqtime_account_process_tick' defined but not used
> 
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Venkatesh Pallipadi <venki@google.com>
> ---
>  kernel/sched.c |   64 ++++++++++++++++++++++++++++----------------------------
>  1 files changed, 32 insertions(+), 32 deletions(-)


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2022-11-21  7:41 Stephen Rothwell
  0 siblings, 0 replies; 89+ messages in thread
From: Stephen Rothwell @ 2022-11-21  7:41 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Ahmed S. Darwish, Bjorn Helgaas, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Documentation/PCI/msi-howto:380: drivers/pci/msi/api.c:148: ERROR: Unexpected indentation.
Documentation/PCI/msi-howto:380: drivers/pci/msi/api.c:149: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/PCI/msi-howto:380: drivers/pci/msi/api.c:236: ERROR: Unexpected indentation.
Documentation/PCI/msi-howto:380: drivers/pci/msi/api.c:259: ERROR: Unexpected indentation.

Introduced by commits

  5c0997dc33ac ("PCI/MSI: Move pci_alloc_irq_vectors() to api.c")
  017239c8db20 ("PCI/MSI: Move pci_irq_vector() to api.c")
  be37b8428b7b ("PCI/MSI: Move pci_irq_get_affinity() to api.c")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2022-05-20  7:49 Stephen Rothwell
  0 siblings, 0 replies; 89+ messages in thread
From: Stephen Rothwell @ 2022-05-20  7:49 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

vmlinux.o: warning: objtool: vc_switch_off_ist+0x76: relocation to !ENDBR: entry_SYSCALL_64+0x15c
vmlinux.o: warning: objtool: vc_switch_off_ist+0x8e: relocation to !ENDBR: entry_SYSCALL_compat+0xa5
vmlinux.o: warning: objtool: vc_switch_off_ist+0x96: relocation to !ENDBR: .entry.text+0x21ca
vmlinux.o: warning: objtool: vc_switch_off_ist+0xee: relocation to !ENDBR: .entry.text+0x162
vmlinux.o: warning: objtool: __sev_es_ist_enter+0x5f: relocation to !ENDBR: entry_SYSCALL_64+0x15c
vmlinux.o: warning: objtool: __sev_es_ist_enter+0x6b: relocation to !ENDBR: .entry.text+0x162
vmlinux.o: warning: objtool: __sev_es_ist_enter+0x89: relocation to !ENDBR: entry_SYSCALL_compat+0xa5
vmlinux.o: warning: objtool: __sev_es_ist_enter+0xc0: relocation to !ENDBR: .entry.text+0x21ca

I don't know what caused this.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-04-27 11:31 ` Borislav Petkov
@ 2022-04-27 13:43   ` Tom Lendacky
  0 siblings, 0 replies; 89+ messages in thread
From: Tom Lendacky @ 2022-04-27 13:43 UTC (permalink / raw)
  To: Borislav Petkov, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

On 4/27/22 06:31, Borislav Petkov wrote:
> On Wed, Apr 27, 2022 at 10:10:59AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (htmldocs) produced
>> these warnings:
>>
>> Documentation/virt/index.rst:7: WARNING: toctree contains reference to nonexisting document 'virt/coco/sev-guest'
>> Documentation/virt/coco/sevguest.rst: WARNING: document isn't included in any toctree
>>
>> Introduced by commit
>>
>>    9617f2f48310 ("virt: sevguest: Rename the sevguest dir and files to sev-guest")
> 
> It looks like Tom forgot to do git mv.
> 
> Fixed now.

Thanks Boris!

Tom

> 
> Thanks!
> 

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-04-27  0:10 Stephen Rothwell
@ 2022-04-27 11:31 ` Borislav Petkov
  2022-04-27 13:43   ` Tom Lendacky
  0 siblings, 1 reply; 89+ messages in thread
From: Borislav Petkov @ 2022-04-27 11:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Tom Lendacky, Linux Kernel Mailing List, Linux Next Mailing List

On Wed, Apr 27, 2022 at 10:10:59AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (htmldocs) produced
> these warnings:
> 
> Documentation/virt/index.rst:7: WARNING: toctree contains reference to nonexisting document 'virt/coco/sev-guest'
> Documentation/virt/coco/sevguest.rst: WARNING: document isn't included in any toctree
> 
> Introduced by commit
> 
>   9617f2f48310 ("virt: sevguest: Rename the sevguest dir and files to sev-guest")

It looks like Tom forgot to do git mv.

Fixed now.

Thanks!

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2022-04-27  0:10 Stephen Rothwell
  2022-04-27 11:31 ` Borislav Petkov
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2022-04-27  0:10 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Tom Lendacky, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Documentation/virt/index.rst:7: WARNING: toctree contains reference to nonexisting document 'virt/coco/sev-guest'
Documentation/virt/coco/sevguest.rst: WARNING: document isn't included in any toctree

Introduced by commit

  9617f2f48310 ("virt: sevguest: Rename the sevguest dir and files to sev-guest")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-15  2:32   ` Stephen Rothwell
@ 2022-04-04  3:26     ` Stephen Rothwell
  0 siblings, 0 replies; 89+ messages in thread
From: Stephen Rothwell @ 2022-04-04  3:26 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

Hi all,

On Tue, 15 Mar 2022 13:32:49 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I gained these new ones after merging today's tip tree:
> 
> arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx512() falls through to next function poly1305_blocks_x86_64()

All we have left are the poly1305_ ones.  They are in Linus' tree now.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-23  2:42                             ` Steven Rostedt
@ 2022-03-23  6:28                               ` Masami Hiramatsu
  0 siblings, 0 replies; 89+ messages in thread
From: Masami Hiramatsu @ 2022-03-23  6:28 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Tue, 22 Mar 2022 22:42:36 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 23 Mar 2022 11:23:23 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > I see the __fexit__ is needed, but why __ftail__ is needed? I guess because
> > func_B is notrace, in that case the __fexit__ will not be in the func_B.
> > Am I correct?
> 
> I believe Peter and I agreed that the "best" solution so far, that has the
> least amount of regressions (doesn't remove anything currently being
> function graph traced, nor removes current tail calls) is:
> 
> > At that point giving us something like:
> > 
> > 1:
> > 	pushsection __ftail_loc
> > 	.long	1b - .
> > 	popsection
> > 
> > 	jmp.d32	func_B
> > 	call	__fexit__
> > 	ret
> 
> 
> Functions with a tail call will not have a __fexit__ and we can not rely on
> the function that is the tail call to do the __fexit__ for the parent
> function. Thus, the compromise is to add a label where the jmp to the
> tail-call function is, and when we want to trace the return of that
> function, we first have to patch the jmp into a call, which will then
> return back to the call to __fexit__.

Got it. So the tail call "jump" will be replaced with a normal call when
we trace it.

That's a good idea :) 


> 
> -- Steve


-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-23  2:23                           ` Masami Hiramatsu
@ 2022-03-23  2:42                             ` Steven Rostedt
  2022-03-23  6:28                               ` Masami Hiramatsu
  0 siblings, 1 reply; 89+ messages in thread
From: Steven Rostedt @ 2022-03-23  2:42 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Wed, 23 Mar 2022 11:23:23 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> I see the __fexit__ is needed, but why __ftail__ is needed? I guess because
> func_B is notrace, in that case the __fexit__ will not be in the func_B.
> Am I correct?

I believe Peter and I agreed that the "best" solution so far, that has the
least amount of regressions (doesn't remove anything currently being
function graph traced, nor removes current tail calls) is:

> At that point giving us something like:
> 
> 1:
> 	pushsection __ftail_loc
> 	.long	1b - .
> 	popsection
> 
> 	jmp.d32	func_B
> 	call	__fexit__
> 	ret


Functions with a tail call will not have a __fexit__ and we can not rely on
the function that is the tail call to do the __fexit__ for the parent
function. Thus, the compromise is to add a label where the jmp to the
tail-call function is, and when we want to trace the return of that
function, we first have to patch the jmp into a call, which will then
return back to the call to __fexit__.

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 14:35                         ` Peter Zijlstra
  2022-03-22 15:04                           ` Steven Rostedt
@ 2022-03-23  2:23                           ` Masami Hiramatsu
  2022-03-23  2:42                             ` Steven Rostedt
  1 sibling, 1 reply; 89+ messages in thread
From: Masami Hiramatsu @ 2022-03-23  2:23 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Steven Rostedt, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, mhiramat, ast, hjl.tools,
	rick.p.edgecombe, rppt, linux-toolchains, Andrew.Cooper3,
	ndesaulniers

On Tue, 22 Mar 2022 15:35:54 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 09:12:42AM -0400, Steven Rostedt wrote:
> 
> > > Suppose:
> > > 
> > > notrace func_B()
> > > {
> > > 	...
> > > }
> > > 
> > > func_A()
> > > {
> > > 	...
> > > 	return func_B();
> > > }
> > > 
> > > then inhibiting tail calls would end up looking like:
> > 
> > If we inhibit tail calls, then we do not need to make func_B notrace.
> 
> Dude, you're arguing in circles :-( the notrace was a given.
> 
> > > func_A:
> > > 	call __fentry__
> > > 	...
> > > 	call func_B
> > > 	call __fexit__
> > > 	ret
> > > 
> > > Then A is fully traced, B is invisible, as per spec. What is the
> > > problem?
> > 
> > The above is fine, but then func_B is not a tail call and can also be
> > traced.
> 
> Again, B is notrace as a given. This was all about how to deal with
> notrace functions.
> 
> I suggested inhibiting tail-call to notrace, you said no. You now seem to
> agree that solves it.
> 
> > > The problem you initially had, of doing a tail-call into a notrace, was
> > > that the __fexit__ call went missing, because notrace will obviously not
> > > have that. But that's avoided by inhibiting all tail-calls between
> > > notrace and !notrace functions (note that notrace must also not
> > > tail-call !notrace).
> > 
> > I'm confused by the above. Why can't a notrace tail call a !notrace?
> > If we tail call to a
> > 
> > func_B:
> > 	call __fentry__
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > then the fentry and fexit show a perfectly valid trace of func_B.
> 
> Bah; I thought I had a case this morning, but now I can't seem to recall
> :/
> 
> > > Your worry seems to stem about loosing visiblilty of !notrace functions,
> > > but AFAICT that doesn't happen.
> > 
> > My worry is:
> > 
> > func_A:
> > 	call __fentry__
> > 	...
> > 	jmp func_B
> > 
> > Where do we do the call __fexit__ ?
> 
> In B (or wherever if B again does a tail-call).
> 
> > That was the original concern, and I think the proposed solutions have
> > convoluted our thoughts about what we are trying to fix. So let's go back
> > to the beginning, and see how to deal with it.
> > 
> > That is, we have:
> > 
> > func_C:
> > 	call __fenty__
> > 	...
> > 	call func_A:
> > 	...
> > 	call func_B:
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > func_A:
> > 	call __fentry__
> > 	...
> 	call __ftail__
> > 	jmp func_B
> > 
> > func_B:
> > 	call __fentry__
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > Where the above is C calling A and B as normal functions, A calling B as a
> > tail call and B just being a normal function called by both A and C (and
> > many other functions).
> 
> We need the __ftail__ thing to mark the trace-stack entry of func_A as
> complete, then any future __fexit__ will be able to pop all completed
> entries.
> 
> In recap:
> 
> 	__fentry__ -- push on trace-stack
> 	__ftail__  -- mark top-most entry complete
> 	__fexit__  -- mark top-most entry complete;
> 	              pop all completed entries
> 
> inhibit tail-calls to notrace.
> 
> > And note, I do not want to limit function tracing (which does not rely on
> > __fexit__) just because we can't figure out how to handle __fexit__.
> 
> I'm not following. Regular function tracing needs none of this.
> 
> It's function graph tracing, kretprobes and whatever else this rethook
> stuff is about that needs this because return trampolines will stop
> working somewhere in the not too distant future.

I see the __fexit__ is needed, but why __ftail__ is needed? I guess because
func_B is notrace, in that case the __fexit__ will not be in the func_B.
Am I correct?

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 21:52 ` Peter Zijlstra
@ 2022-03-22 23:11   ` Stephen Rothwell
  0 siblings, 0 replies; 89+ messages in thread
From: Stephen Rothwell @ 2022-03-22 23:11 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

Hi Peter,

On Tue, 22 Mar 2022 22:52:52 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Mar 22, 2022 at 02:51:08PM +1100, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > produced these warnings:
> > 
> > WARNING: modpost: EXPORT symbol "device_match_devt" [vmlinux] version ...
> > Is "device_match_devt" prototyped in <asm/asm-prototypes.h>?
> > 
> > I get thousands like this :-(
> > 
> > I don't know what has done this, but there is a new Kbuild and modpost
> > change:
> > 
> >   2f35e67f621f ("kbuild: Fixup the IBT kbuild changes")  
> 
> It was; I rebased that commit and asked Boris to regen tip so you should
> have it fixed for the next round.

Excellent thanks (I just picked up the new tip tree).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22  3:51 Stephen Rothwell
@ 2022-03-22 21:52 ` Peter Zijlstra
  2022-03-22 23:11   ` Stephen Rothwell
  0 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22 21:52 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Mar 22, 2022 at 02:51:08PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
> 
> WARNING: modpost: EXPORT symbol "device_match_devt" [vmlinux] version ...
> Is "device_match_devt" prototyped in <asm/asm-prototypes.h>?
> 
> I get thousands like this :-(
> 
> I don't know what has done this, but there is a new Kbuild and modpost
> change:
> 
>   2f35e67f621f ("kbuild: Fixup the IBT kbuild changes")

It was; I rebased that commit and asked Boris to regen tip so you should
have it fixed for the next round.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 15:48                             ` Peter Zijlstra
@ 2022-03-22 16:17                               ` Steven Rostedt
  0 siblings, 0 replies; 89+ messages in thread
From: Steven Rostedt @ 2022-03-22 16:17 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, 22 Mar 2022 16:48:02 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 11:04:38AM -0400, Steven Rostedt wrote:
> 
> > > In recap:
> > > 
> > > 	__fentry__ -- push on trace-stack
> > > 	__ftail__  -- mark top-most entry complete
> > > 	__fexit__  -- mark top-most entry complete;
> > > 	              pop all completed entries  
> > 
> > Again, this would require that the tail-calls are also being traced.  
> 
> Which is why we should inhibit tail-calls if the function is notrace.
> 
> > > inhibit tail-calls to notrace.  
> > 
> > Just inhibiting tail-calls to notrace would work without any of the above.  
> 
> I'm lost again; what? Without any of the above you got nothing because
> return-trampoline will not work.


I think this got "lost in translation".

 "Inhibiting tail-calls to notrace"

Is a bit ambiguous because of the "to notrace" which would be different if
I had said "on notrace" which I may have screwed up the grammar here. Let
me be more precise.

 "Limiting tail-calls to only notrace functions"

That I think is a bit less ambiguous. English sucks.

> 
> > But my fear is that will cause a noticeable performance impact.  
> 
> Most code isn't in fact notrace, and call+ret aren't *that* expensive.

  "isn't in fact notrace" Ug! Double negatives!

This gets even more confusing when we are saying "notrace" which is a
negative. We should probably just say "traced" functions which makes
communication a bit more straight forward.

> 
> > > It's function graph tracing, kretprobes and whatever else this rethook
> > > stuff is about that needs this because return trampolines will stop
> > > working somewhere in the not too distant future.  
> > 
> > Another crazy solution is to have:
> > 
> > func_A:
> > 	call __fentry__
> > 	...
> > tail:	jmp 1f 
> > 	call 1f  
> 	
> > 	call __fexit__
> > 	ret
> > 1:	jmp func_B
> > 
> > 
> > where the compiler tells us about "tail:" and that we know that func_A ends
> > with a tail call, and if we want to trace the end of func_A we convert that
> > jmp 1f into a nop. And then we call the func_B and it's return comes back
> > to where we call __fexit__ and then return normally.  
> 
> At that point giving us something like:
> 
> 1:
> 	pushsection __ftail_loc
> 	.long	1b - .
> 	popsection
> 
> 	jmp.d32	func_B
> 	call	__fexit__
> 	ret
> 
> is smaller and simpler, we can patch the jmp.d32 to call when tracing.
> The only problem is SLS, that might wants an int3 after jmp too
> ( https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1026 ).
> 
> That does avoid the need for __ftail__ I suppose.

Which is basically what I said earlier ;-)

  https://lore.kernel.org/all/20220321122259.28146a7a@gandalf.local.home/

> Or maybe another solution is:
> 
> funcA:
> 	[..]
> 	jmp funcB
> 	call __fexit__
> 	ret
> 
> And if funcA is being traced, we change jmp to a call.
> 
> 	[..]
> 	call funcB
> 	call __fexit__
> 	ret
> 
> Such that we only remove the tail calls if we enable tracing on the
> function with the tail call.

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 15:04                           ` Steven Rostedt
  2022-03-22 15:19                             ` Peter Zijlstra
@ 2022-03-22 15:48                             ` Peter Zijlstra
  2022-03-22 16:17                               ` Steven Rostedt
  1 sibling, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22 15:48 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, Mar 22, 2022 at 11:04:38AM -0400, Steven Rostedt wrote:

> > In recap:
> > 
> > 	__fentry__ -- push on trace-stack
> > 	__ftail__  -- mark top-most entry complete
> > 	__fexit__  -- mark top-most entry complete;
> > 	              pop all completed entries
> 
> Again, this would require that the tail-calls are also being traced.

Which is why we should inhibit tail-calls if the function is notrace.

> > inhibit tail-calls to notrace.
> 
> Just inhibiting tail-calls to notrace would work without any of the above.

I'm lost again; what? Without any of the above you got nothing because
return-trampoline will not work.

> But my fear is that will cause a noticeable performance impact.

Most code isn't in fact notrace, and call+ret aren't *that* expensive.

> > It's function graph tracing, kretprobes and whatever else this rethook
> > stuff is about that needs this because return trampolines will stop
> > working somewhere in the not too distant future.
> 
> Another crazy solution is to have:
> 
> func_A:
> 	call __fentry__
> 	...
> tail:	jmp 1f 
> 	call 1f
	
> 	call __fexit__
> 	ret
> 1:	jmp func_B
> 
> 
> where the compiler tells us about "tail:" and that we know that func_A ends
> with a tail call, and if we want to trace the end of func_A we convert that
> jmp 1f into a nop. And then we call the func_B and it's return comes back
> to where we call __fexit__ and then return normally.

At that point giving us something like:

1:
	pushsection __ftail_loc
	.long	1b - .
	popsection

	jmp.d32	func_B
	call	__fexit__
	ret

is smaller and simpler, we can patch the jmp.d32 to call when tracing.
The only problem is SLS, that might wants an int3 after jmp too
( https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1026 ).

That does avoid the need for __ftail__ I suppose.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 15:04                           ` Steven Rostedt
@ 2022-03-22 15:19                             ` Peter Zijlstra
  2022-03-22 15:48                             ` Peter Zijlstra
  1 sibling, 0 replies; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22 15:19 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, Mar 22, 2022 at 11:04:38AM -0400, Steven Rostedt wrote:
> On Tue, 22 Mar 2022 15:35:54 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:

> > I suggested inhibiting tail-call to notrace, you said no. You now seem to
> > agree that solves it.
> 
> I said inhibiting tail-calls was a solution, but only inhibiting it to
> notrace would probably have a significant performance impact.
> 
> I thought you were talking about adding notrace to tail calls, not the
> other way around. Maybe that is our confusion in this conversation.

Yeah, I meant inhibiting the compiler from doing tail-calls.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 14:35                         ` Peter Zijlstra
@ 2022-03-22 15:04                           ` Steven Rostedt
  2022-03-22 15:19                             ` Peter Zijlstra
  2022-03-22 15:48                             ` Peter Zijlstra
  2022-03-23  2:23                           ` Masami Hiramatsu
  1 sibling, 2 replies; 89+ messages in thread
From: Steven Rostedt @ 2022-03-22 15:04 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, 22 Mar 2022 15:35:54 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 09:12:42AM -0400, Steven Rostedt wrote:
> 
> > > Suppose:
> > > 
> > > notrace func_B()
> > > {
> > > 	...
> > > }
> > > 
> > > func_A()
> > > {
> > > 	...
> > > 	return func_B();
> > > }
> > > 
> > > then inhibiting tail calls would end up looking like:  
> > 
> > If we inhibit tail calls, then we do not need to make func_B notrace.  
> 
> Dude, you're arguing in circles :-( the notrace was a given.

Why is it notrace? Sorry to be dense, but it's not a given to me.

> 
> > > func_A:
> > > 	call __fentry__
> > > 	...
> > > 	call func_B
> > > 	call __fexit__
> > > 	ret
> > > 
> > > Then A is fully traced, B is invisible, as per spec. What is the
> > > problem?  
> > 
> > The above is fine, but then func_B is not a tail call and can also be
> > traced.  
> 
> Again, B is notrace as a given. This was all about how to deal with
> notrace functions.


No, it was about how to deal with notrace functions that were tail calls.
That was what I had an issue with. Because the solution you proposed had
func_A depend on func_B executing its call __fexit__ which it would not, if
it was not traced.

> 
> I suggested inhibiting tail-call to notrace, you said no. You now seem to
> agree that solves it.

I said inhibiting tail-calls was a solution, but only inhibiting it to
notrace would probably have a significant performance impact.

I thought you were talking about adding notrace to tail calls, not the
other way around. Maybe that is our confusion in this conversation.

> 
> > > The problem you initially had, of doing a tail-call into a notrace, was
> > > that the __fexit__ call went missing, because notrace will obviously not
> > > have that. But that's avoided by inhibiting all tail-calls between
> > > notrace and !notrace functions (note that notrace must also not
> > > tail-call !notrace).  
> > 
> > I'm confused by the above. Why can't a notrace tail call a !notrace?
> > If we tail call to a
> > 
> > func_B:
> > 	call __fentry__
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > then the fentry and fexit show a perfectly valid trace of func_B.  
> 
> Bah; I thought I had a case this morning, but now I can't seem to recall
> :/

That happens to all of us ;-)

> 
> > > Your worry seems to stem about loosing visiblilty of !notrace functions,
> > > but AFAICT that doesn't happen.  
> > 
> > My worry is:
> > 
> > func_A:
> > 	call __fentry__
> > 	...
> > 	jmp func_B
> > 
> > Where do we do the call __fexit__ ?  
> 
> In B (or wherever if B again does a tail-call).

But there's no guarantee that the call __fexit__ will not be a nop in
func_B. Remember, these are all turned on and off. If we just trace func_A
and not func_B, we will never have a call __fexit__ for func_A.

> 
> > That was the original concern, and I think the proposed solutions have
> > convoluted our thoughts about what we are trying to fix. So let's go back
> > to the beginning, and see how to deal with it.
> > 
> > That is, we have:
> > 
> > func_C:
> > 	call __fenty__
> > 	...
> > 	call func_A:
> > 	...
> > 	call func_B:
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > func_A:
> > 	call __fentry__
> > 	...  
> 	call __ftail__
> > 	jmp func_B
> > 
> > func_B:
> > 	call __fentry__
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > Where the above is C calling A and B as normal functions, A calling B as a
> > tail call and B just being a normal function called by both A and C (and
> > many other functions).  
> 
> We need the __ftail__ thing to mark the trace-stack entry of func_A as
> complete, then any future __fexit__ will be able to pop all completed
> entries.
> 
> In recap:
> 
> 	__fentry__ -- push on trace-stack
> 	__ftail__  -- mark top-most entry complete
> 	__fexit__  -- mark top-most entry complete;
> 	              pop all completed entries

Again, this would require that the tail-calls are also being traced.

> 
> inhibit tail-calls to notrace.

Just inhibiting tail-calls to notrace would work without any of the above.
But my fear is that will cause a noticeable performance impact.

> 
> > And note, I do not want to limit function tracing (which does not rely on
> > __fexit__) just because we can't figure out how to handle __fexit__.  
> 
> I'm not following. Regular function tracing needs none of this.

The regular function tracing does not need this. Only function graph
tracing. I was thinking you were *adding* notrace to tail calls and such,
which is what I was against. But apparently that is not what you were
saying.

> 
> It's function graph tracing, kretprobes and whatever else this rethook
> stuff is about that needs this because return trampolines will stop
> working somewhere in the not too distant future.

Another crazy solution is to have:

func_A:
	call __fentry__
	...
tail:	jmp 1f 
	call 1f
	call __fexit__
	ret
1:	jmp func_B


where the compiler tells us about "tail:" and that we know that func_A ends
with a tail call, and if we want to trace the end of func_A we convert that
jmp 1f into a nop. And then we call the func_B and it's return comes back
to where we call __fexit__ and then return normally.

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 13:12                       ` Steven Rostedt
@ 2022-03-22 14:35                         ` Peter Zijlstra
  2022-03-22 15:04                           ` Steven Rostedt
  2022-03-23  2:23                           ` Masami Hiramatsu
  0 siblings, 2 replies; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22 14:35 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, Mar 22, 2022 at 09:12:42AM -0400, Steven Rostedt wrote:

> > Suppose:
> > 
> > notrace func_B()
> > {
> > 	...
> > }
> > 
> > func_A()
> > {
> > 	...
> > 	return func_B();
> > }
> > 
> > then inhibiting tail calls would end up looking like:
> 
> If we inhibit tail calls, then we do not need to make func_B notrace.

Dude, you're arguing in circles :-( the notrace was a given.

> > func_A:
> > 	call __fentry__
> > 	...
> > 	call func_B
> > 	call __fexit__
> > 	ret
> > 
> > Then A is fully traced, B is invisible, as per spec. What is the
> > problem?
> 
> The above is fine, but then func_B is not a tail call and can also be
> traced.

Again, B is notrace as a given. This was all about how to deal with
notrace functions.

I suggested inhibiting tail-call to notrace, you said no. You now seem to
agree that solves it.

> > The problem you initially had, of doing a tail-call into a notrace, was
> > that the __fexit__ call went missing, because notrace will obviously not
> > have that. But that's avoided by inhibiting all tail-calls between
> > notrace and !notrace functions (note that notrace must also not
> > tail-call !notrace).
> 
> I'm confused by the above. Why can't a notrace tail call a !notrace?
> If we tail call to a
> 
> func_B:
> 	call __fentry__
> 	...
> 	call __fexit__
> 	ret
> 
> then the fentry and fexit show a perfectly valid trace of func_B.

Bah; I thought I had a case this morning, but now I can't seem to recall
:/

> > Your worry seems to stem about loosing visiblilty of !notrace functions,
> > but AFAICT that doesn't happen.
> 
> My worry is:
> 
> func_A:
> 	call __fentry__
> 	...
> 	jmp func_B
> 
> Where do we do the call __fexit__ ?

In B (or wherever if B again does a tail-call).

> That was the original concern, and I think the proposed solutions have
> convoluted our thoughts about what we are trying to fix. So let's go back
> to the beginning, and see how to deal with it.
> 
> That is, we have:
> 
> func_C:
> 	call __fenty__
> 	...
> 	call func_A:
> 	...
> 	call func_B:
> 	...
> 	call __fexit__
> 	ret
> 
> func_A:
> 	call __fentry__
> 	...
	call __ftail__
> 	jmp func_B
> 
> func_B:
> 	call __fentry__
> 	...
> 	call __fexit__
> 	ret
> 
> Where the above is C calling A and B as normal functions, A calling B as a
> tail call and B just being a normal function called by both A and C (and
> many other functions).

We need the __ftail__ thing to mark the trace-stack entry of func_A as
complete, then any future __fexit__ will be able to pop all completed
entries.

In recap:

	__fentry__ -- push on trace-stack
	__ftail__  -- mark top-most entry complete
	__fexit__  -- mark top-most entry complete;
	              pop all completed entries

inhibit tail-calls to notrace.

> And note, I do not want to limit function tracing (which does not rely on
> __fexit__) just because we can't figure out how to handle __fexit__.

I'm not following. Regular function tracing needs none of this.

It's function graph tracing, kretprobes and whatever else this rethook
stuff is about that needs this because return trampolines will stop
working somewhere in the not too distant future.


^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:12         ` Steven Rostedt
  2022-03-21 16:15           ` Steven Rostedt
@ 2022-03-22 14:25           ` Masami Hiramatsu
  1 sibling, 0 replies; 89+ messages in thread
From: Masami Hiramatsu @ 2022-03-22 14:25 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, mhiramat, ast, hjl.tools,
	rick.p.edgecombe, rppt, linux-toolchains, Andrew.Cooper3,
	ndesaulniers

On Mon, 21 Mar 2022 12:12:09 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 21 Mar 2022 17:04:28 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Mon, Mar 21, 2022 at 11:28:05AM -0400, Steven Rostedt wrote:
> > > On Mon, 21 Mar 2022 14:04:05 +0100
> > > Peter Zijlstra <peterz@infradead.org> wrote:  
> > 
> > > > Also, folks, I'm thinking we should start to move to __fexit__, if CET
> > > > SHSTK ever wants to come to kernel land return trampolines will
> > > > insta-stop working.
> > > > 
> > > > Hjl, do you think we could get -mfexit to go along with -mfentry ?  
> > 
> > > int funcA () {
> > > 	[..]
> > > 	return funcB();
> > > }  
> > 
> > > This currently works with function graph and kretprobe tracing because of
> > > the shadow stack. Let's say we traced both funcA and funcB
> > > 
> > > funcA:
> > > 	call __fentry__  
> > 			push funcA on trace-stack
> > > 
> > > 	[..]
> > > 	jmp funcB
> > > 
> > > funcB:
> > > 	call __fentry__  
> > 			push funcB on trace-stack
> > > 
> > > 	[..]  
> > 	call __fexit__
> > 			pop trace-stack until empty

This seems wrong. We don't pop the trace-stack until empty, but we will
record the real stack pointer at funcA.

> > 			  'exit funcB'
> > 			  'exit funcA'
> 
> And what happens if funcC called funcA and it too was on the stack. We pop
> that too? But it's not done yet, because calling of funcA was not a tail
> call.

Thus when the funcC is called, the trace-stack will be poped until funcA,
because we can see the real stack pointer at the 'ret'.
So the funcC is still on the trace-stack after that.

Thank you,


> 
> -- Steve
> 
> 
> > 
> > > 	ret  
> > 
> > > 
> > > That is, the current algorithm traces the end of both funcA and funcB
> > > without issue, because of how the shadow stack works.  
> > 
> > And it all works, no? Or what am I missing?
> 
> 
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 13:15         ` Mark Rutland
@ 2022-03-22 13:51           ` Masami Hiramatsu
  0 siblings, 0 replies; 89+ messages in thread
From: Masami Hiramatsu @ 2022-03-22 13:51 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, rostedt, ast, hjl.tools,
	rick.p.edgecombe, rppt, linux-toolchains, Andrew.Cooper3,
	ndesaulniers

On Tue, 22 Mar 2022 13:15:58 +0000
Mark Rutland <mark.rutland@arm.com> wrote:

> On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> > On Mon, 21 Mar 2022 17:48:54 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > > produced these new warnings:
> > > > > > 
> > > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > 
> > > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > > those.
> > > > 
> > > > Ahh, something tracing. I'll go do some patches on top of it.
> > > 
> > > The below gets rid of the objtool warnings.
> > 
> > Yes, I confirmed that.
> > 
> > > But I still think it's fairly terrible to get a (flawed) carbon copy of
> > > the kretprobe code.
> > 
> > Indeed. I would like to replace the trampoline code of kretprobe with
> > rethook, eventually. There is no reason why we keep the clone.
> > (But I need more arch maintainers help for that, there are too many
> >  archs implemented kretprobes)
> 
> FWIW, I'm more than happy to help on the arm64 side if you could Cc me for
> that; I'm aware of other things in this area I'd like to clean up for
> backtracing, too.

Thank you for your warm help. OK, let me update and submit the rethook
for arm64 :-)

Thanks.

-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 12:46           ` Masami Hiramatsu
@ 2022-03-22 13:22             ` Steven Rostedt
  0 siblings, 0 replies; 89+ messages in thread
From: Steven Rostedt @ 2022-03-22 13:22 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Tue, 22 Mar 2022 21:46:29 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> > > Indeed. I would like to replace the trampoline code of kretprobe with
> > > rethook, eventually. There is no reason why we keep the clone.
> > > (But I need more arch maintainers help for that, there are too many
> > >  archs implemented kretprobes)  
> > 
> > CONFIG_KPROBE_ON_RETHOOK - and then implement archs one by one?  
> 
> Sounds good! Maybe we will see different data structure fields
> which depends on that config, but those are internal fields, so
> user will not access it.

Which is basically what I do for ftrace. Which is why we have all these:

        select HAVE_DYNAMIC_FTRACE
        select HAVE_DYNAMIC_FTRACE_WITH_REGS
        select HAVE_DYNAMIC_FTRACE_WITH_ARGS
        select HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
        select HAVE_SAMPLE_FTRACE_DIRECT
        select HAVE_SAMPLE_FTRACE_DIRECT_MULTI

in the architecture Kconfigs.

-- Steve


^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22  5:31       ` Masami Hiramatsu
  2022-03-22  8:08         ` Peter Zijlstra
  2022-03-22 12:17         ` Peter Zijlstra
@ 2022-03-22 13:15         ` Mark Rutland
  2022-03-22 13:51           ` Masami Hiramatsu
  2 siblings, 1 reply; 89+ messages in thread
From: Mark Rutland @ 2022-03-22 13:15 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, rostedt, ast, hjl.tools,
	rick.p.edgecombe, rppt, linux-toolchains, Andrew.Cooper3,
	ndesaulniers

On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> On Mon, 21 Mar 2022 17:48:54 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > produced these new warnings:
> > > > > 
> > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > 
> > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > those.
> > > 
> > > Ahh, something tracing. I'll go do some patches on top of it.
> > 
> > The below gets rid of the objtool warnings.
> 
> Yes, I confirmed that.
> 
> > But I still think it's fairly terrible to get a (flawed) carbon copy of
> > the kretprobe code.
> 
> Indeed. I would like to replace the trampoline code of kretprobe with
> rethook, eventually. There is no reason why we keep the clone.
> (But I need more arch maintainers help for that, there are too many
>  archs implemented kretprobes)

FWIW, I'm more than happy to help on the arm64 side if you could Cc me for
that; I'm aware of other things in this area I'd like to clean up for
backtracing, too.

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22  7:54                     ` Peter Zijlstra
@ 2022-03-22 13:12                       ` Steven Rostedt
  2022-03-22 14:35                         ` Peter Zijlstra
  0 siblings, 1 reply; 89+ messages in thread
From: Steven Rostedt @ 2022-03-22 13:12 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, 22 Mar 2022 08:54:55 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Mar 21, 2022 at 12:54:19PM -0400, Steven Rostedt wrote:
> > On Mon, 21 Mar 2022 17:50:50 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:
> >   
> > > > This also assumes that we need to trace everything that is marked. I
> > > > mentioned in another email, what do we do if we only trace funcA?    
> > > 
> > > Like I said later on; if we inhibit tail-calls to notrace, this goes
> > > away.  
> > 
> > Please no. The number of "notrace" functions is increasing to the point
> > that it's starting to make function tracing useless in a lot of
> > circumstances. I've already lost my ability to see when user space goes
> > into the kernel (which I have to hack up custom coding to enable again).  
> 
> I really can't follow the argument there, nor on IRC.
> 
> Suppose:
> 
> notrace func_B()
> {
> 	...
> }
> 
> func_A()
> {
> 	...
> 	return func_B();
> }
> 
> then inhibiting tail calls would end up looking like:

If we inhibit tail calls, then we do not need to make func_B notrace.

> 
> func_A:
> 	call __fentry__
> 	...
> 	call func_B
> 	call __fexit__
> 	ret
> 
> Then A is fully traced, B is invisible, as per spec. What is the
> problem?

The above is fine, but then func_B is not a tail call and can also be
traced.

> 
> The problem you initially had, of doing a tail-call into a notrace, was
> that the __fexit__ call went missing, because notrace will obviously not
> have that. But that's avoided by inhibiting all tail-calls between
> notrace and !notrace functions (note that notrace must also not
> tail-call !notrace).

I'm confused by the above. Why can't a notrace tail call a !notrace?
If we tail call to a

func_B:
	call __fentry__
	...
	call __fexit__
	ret

then the fentry and fexit show a perfectly valid trace of func_B.


> 
> Your worry seems to stem about loosing visiblilty of !notrace functions,
> but AFAICT that doesn't happen.

My worry is:

func_A:
	call __fentry__
	...
	jmp func_B

Where do we do the call __fexit__ ?

That was the original concern, and I think the proposed solutions have
convoluted our thoughts about what we are trying to fix. So let's go back
to the beginning, and see how to deal with it.

That is, we have:

func_C:
	call __fenty__
	...
	call func_A:
	...
	call func_B:
	...
	call __fexit__
	ret

func_A:
	call __fentry__
	...
	jmp func_B

func_B:
	call __fentry__
	...
	call __fexit__
	ret

Where the above is C calling A and B as normal functions, A calling B as a
tail call and B just being a normal function called by both A and C (and
many other functions).

And note, I do not want to limit function tracing (which does not rely on
__fexit__) just because we can't figure out how to handle __fexit__.

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 12:17         ` Peter Zijlstra
@ 2022-03-22 12:46           ` Masami Hiramatsu
  2022-03-22 13:22             ` Steven Rostedt
  0 siblings, 1 reply; 89+ messages in thread
From: Masami Hiramatsu @ 2022-03-22 12:46 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, rostedt, ast,
	hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, 22 Mar 2022 13:17:18 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> 
> > > But I still think it's fairly terrible to get a (flawed) carbon copy of
> > > the kretprobe code.
> > 
> > Indeed. I would like to replace the trampoline code of kretprobe with
> > rethook, eventually. There is no reason why we keep the clone.
> > (But I need more arch maintainers help for that, there are too many
> >  archs implemented kretprobes)
> 
> CONFIG_KPROBE_ON_RETHOOK - and then implement archs one by one?

Sounds good! Maybe we will see different data structure fields
which depends on that config, but those are internal fields, so
user will not access it.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22  5:31       ` Masami Hiramatsu
  2022-03-22  8:08         ` Peter Zijlstra
@ 2022-03-22 12:17         ` Peter Zijlstra
  2022-03-22 12:46           ` Masami Hiramatsu
  2022-03-22 13:15         ` Mark Rutland
  2 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22 12:17 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, rostedt, ast,
	hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:

> > But I still think it's fairly terrible to get a (flawed) carbon copy of
> > the kretprobe code.
> 
> Indeed. I would like to replace the trampoline code of kretprobe with
> rethook, eventually. There is no reason why we keep the clone.
> (But I need more arch maintainers help for that, there are too many
>  archs implemented kretprobes)

CONFIG_KPROBE_ON_RETHOOK - and then implement archs one by one?

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22  9:14           ` Masami Hiramatsu
@ 2022-03-22 12:07             ` Peter Zijlstra
  0 siblings, 0 replies; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22 12:07 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, rostedt, ast,
	hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, Mar 22, 2022 at 06:14:54PM +0900, Masami Hiramatsu wrote:
> On Tue, 22 Mar 2022 09:08:22 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> > 
> > > > Also, I think both should fix regs->ss.
> > > 
> > > I'm not sure this part. Since the return trampoline should run in the same
> > > context of the called function, isn't ss same there too?
> > 
> > It creates pt_regs on the stack, so the trampolines do:
> > 
> > 	push $arch_rethook_trampoline
> > 	push %rsp
> > 	pushf
> > 	sub $24, %rsp /* cs, ip, orig_ax */
> > 	push %rdi
> > 	...
> > 	push %r15
> > 
> > That means that if anybody looks at regs->ss, it'll find
> > $arch_rethook_trampoline, which isn't a valid segment descriptor, or am
> > I just really bad at counting today?
> 
> Ah, got it. It seems that the ss was skipped from the beginning, and
> no one argued that.

Yeah, this is a long-standing issue, but I noticed it when looking at
the code yesterday.

> > I'm thinking you want a copy of __KERNEL_DS in that stack slot, not a
> > function pointer.
> 
> The function pointer is for unwinding stack which involves the kretprobe.
> Anyway, I can add a slot for ss if it is neeeded. But if it always be
> __KERNEL_DS, is it worth to save it?

Probably, to save someone future head-aches. The insn-eval.c stuff will
actually look at SS when it tries to decode BP/SP fields, and I've got
vague memories of actually using that a while ago. I think I was playing
around with double-fault and the whole espfix64 mess and hit the ESPFIX
segment.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22 10:46   ` Peter Zijlstra
@ 2022-03-22 10:59     ` Peter Zijlstra
  0 siblings, 0 replies; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22 10:59 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, linux-crypto,
	ebiggers, herbert, Jason, Josh Poimboeuf

On Tue, Mar 22, 2022 at 11:46:04AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:

> > > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
> > > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
> > > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
> > 
> > Yes, those are somewhere on the todo list, lemme bump them.

The poly one is a little more involved since it's a perl script writing
asm O_O

Looking at the generated asm tough, the these are conditional tail-calls
and objtool *should* recognise them but doesn't...

This seems to cure.

---
 tools/objtool/check.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 6de5085e3e5a..b848e1ddd5d8 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1239,11 +1239,20 @@ static bool same_function(struct instruction *insn1, struct instruction *insn2)
 	return insn1->func->pfunc == insn2->func->pfunc;
 }
 
-static bool is_first_func_insn(struct instruction *insn)
+static bool is_first_func_insn(struct objtool_file *file, struct instruction *insn)
 {
-	return insn->offset == insn->func->offset ||
-	       (insn->type == INSN_ENDBR &&
-		insn->offset == insn->func->offset + insn->len);
+	if (insn->offset == insn->func->offset)
+		return true;
+
+	if (ibt) {
+		struct instruction *prev = prev_insn_same_sym(file, insn);
+
+		if (prev && prev->type == INSN_ENDBR &&
+		    insn->offset == insn->func->offset + prev->len)
+			return true;
+	}
+
+	return false;
 }
 
 /*
@@ -1327,7 +1336,7 @@ static int add_jump_destinations(struct objtool_file *file)
 				insn->jump_dest->func->pfunc = insn->func;
 
 			} else if (!same_function(insn, insn->jump_dest) &&
-				   is_first_func_insn(insn->jump_dest)) {
+				   is_first_func_insn(file, insn->jump_dest)) {
 				/* internal sibling call (without reloc) */
 				add_call_dest(file, insn, insn->jump_dest->func, true);
 			}


^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 12:55 ` Peter Zijlstra
  2022-03-21 13:04   ` Peter Zijlstra
@ 2022-03-22 10:46   ` Peter Zijlstra
  2022-03-22 10:59     ` Peter Zijlstra
  1 sibling, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22 10:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, linux-crypto,
	ebiggers, herbert, Jason

On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:

> > [ Note I was already getting these:
> > arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> > arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
> > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
> > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
> 
> Yes, those are somewhere on the todo list, lemme bump them.

So the chacha one seems relatively simple, see below.

---
diff --git a/arch/x86/crypto/chacha-avx512vl-x86_64.S b/arch/x86/crypto/chacha-avx512vl-x86_64.S
index 946f74dd6fba..259383e1ad44 100644
--- a/arch/x86/crypto/chacha-avx512vl-x86_64.S
+++ b/arch/x86/crypto/chacha-avx512vl-x86_64.S
@@ -172,7 +172,7 @@ SYM_FUNC_START(chacha_2block_xor_avx512vl)
 	# xor remaining bytes from partial register into output
 	mov		%rcx,%rax
 	and		$0xf,%rcx
-	jz		.Ldone8
+	jz		.Ldone2
 	mov		%rax,%r9
 	and		$~0xf,%r9
 
@@ -438,7 +438,7 @@ SYM_FUNC_START(chacha_4block_xor_avx512vl)
 	# xor remaining bytes from partial register into output
 	mov		%rcx,%rax
 	and		$0xf,%rcx
-	jz		.Ldone8
+	jz		.Ldone4
 	mov		%rax,%r9
 	and		$~0xf,%r9
 

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22  8:08         ` Peter Zijlstra
@ 2022-03-22  9:14           ` Masami Hiramatsu
  2022-03-22 12:07             ` Peter Zijlstra
  0 siblings, 1 reply; 89+ messages in thread
From: Masami Hiramatsu @ 2022-03-22  9:14 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, rostedt, ast,
	hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, 22 Mar 2022 09:08:22 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> 
> > > Also, I think both should fix regs->ss.
> > 
> > I'm not sure this part. Since the return trampoline should run in the same
> > context of the called function, isn't ss same there too?
> 
> It creates pt_regs on the stack, so the trampolines do:
> 
> 	push $arch_rethook_trampoline
> 	push %rsp
> 	pushf
> 	sub $24, %rsp /* cs, ip, orig_ax */
> 	push %rdi
> 	...
> 	push %r15
> 
> That means that if anybody looks at regs->ss, it'll find
> $arch_rethook_trampoline, which isn't a valid segment descriptor, or am
> I just really bad at counting today?

Ah, got it. It seems that the ss was skipped from the beginning, and
no one argued that.

> I'm thinking you want a copy of __KERNEL_DS in that stack slot, not a
> function pointer.

The function pointer is for unwinding stack which involves the kretprobe.
Anyway, I can add a slot for ss if it is neeeded. But if it always be
__KERNEL_DS, is it worth to save it?

Thank you,


-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22  5:31       ` Masami Hiramatsu
@ 2022-03-22  8:08         ` Peter Zijlstra
  2022-03-22  9:14           ` Masami Hiramatsu
  2022-03-22 12:17         ` Peter Zijlstra
  2022-03-22 13:15         ` Mark Rutland
  2 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22  8:08 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, rostedt, ast,
	hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:

> > Also, I think both should fix regs->ss.
> 
> I'm not sure this part. Since the return trampoline should run in the same
> context of the called function, isn't ss same there too?

It creates pt_regs on the stack, so the trampolines do:

	push $arch_rethook_trampoline
	push %rsp
	pushf
	sub $24, %rsp /* cs, ip, orig_ax */
	push %rdi
	...
	push %r15

That means that if anybody looks at regs->ss, it'll find
$arch_rethook_trampoline, which isn't a valid segment descriptor, or am
I just really bad at counting today?

I'm thinking you want a copy of __KERNEL_DS in that stack slot, not a
function pointer.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:54                   ` Steven Rostedt
@ 2022-03-22  7:54                     ` Peter Zijlstra
  2022-03-22 13:12                       ` Steven Rostedt
  0 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22  7:54 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 12:54:19PM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 17:50:50 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > > This also assumes that we need to trace everything that is marked. I
> > > mentioned in another email, what do we do if we only trace funcA?  
> > 
> > Like I said later on; if we inhibit tail-calls to notrace, this goes
> > away.
> 
> Please no. The number of "notrace" functions is increasing to the point
> that it's starting to make function tracing useless in a lot of
> circumstances. I've already lost my ability to see when user space goes
> into the kernel (which I have to hack up custom coding to enable again).

I really can't follow the argument there, nor on IRC.

Suppose:

notrace func_B()
{
	...
}

func_A()
{
	...
	return func_B();
}

then inhibiting tail calls would end up looking like:

func_A:
	call __fentry__
	...
	call func_B
	call __fexit__
	ret

Then A is fully traced, B is invisible, as per spec. What is the
problem?

The problem you initially had, of doing a tail-call into a notrace, was
that the __fexit__ call went missing, because notrace will obviously not
have that. But that's avoided by inhibiting all tail-calls between
notrace and !notrace functions (note that notrace must also not
tail-call !notrace).

Your worry seems to stem about loosing visiblilty of !notrace functions,
but AFAICT that doesn't happen.


^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 22:12                     ` Alexei Starovoitov
  2022-03-21 22:46                       ` Stephen Rothwell
@ 2022-03-22  7:42                       ` Peter Zijlstra
  1 sibling, 0 replies; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-22  7:42 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Stephen Rothwell, Daniel Borkmann, Andrii Nakryiko,
	Linus Torvalds, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Steven Rostedt, Alexei Starovoitov, H.J. Lu,
	Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers, bpf, Networking, David Miller,
	Jakub Kicinski

On Mon, Mar 21, 2022 at 03:12:05PM -0700, Alexei Starovoitov wrote:
> 
> That makes little sense. It's not an unusual merge conflict.

It is not only that; it is adding code that with an x86 arch maintainer
hat on I've never seen and don't agree with. Same for arm64 apparently.


^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:48     ` Peter Zijlstra
@ 2022-03-22  5:31       ` Masami Hiramatsu
  2022-03-22  8:08         ` Peter Zijlstra
                           ` (2 more replies)
  0 siblings, 3 replies; 89+ messages in thread
From: Masami Hiramatsu @ 2022-03-22  5:31 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	rostedt, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Mon, 21 Mar 2022 17:48:54 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > produced these new warnings:
> > > > 
> > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > 
> > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > those.
> > 
> > Ahh, something tracing. I'll go do some patches on top of it.
> 
> The below gets rid of the objtool warnings.

Yes, I confirmed that.

> 
> But I still think it's fairly terrible to get a (flawed) carbon copy of
> the kretprobe code.

Indeed. I would like to replace the trampoline code of kretprobe with
rethook, eventually. There is no reason why we keep the clone.
(But I need more arch maintainers help for that, there are too many
 archs implemented kretprobes)

> Also, I think both should fix regs->ss.

I'm not sure this part. Since the return trampoline should run in the same
context of the called function, isn't ss same there too?

Thank you,

> 
> ---
> diff --git a/arch/x86/kernel/rethook.c b/arch/x86/kernel/rethook.c
> index f0f2f0608282..227a1890a984 100644
> --- a/arch/x86/kernel/rethook.c
> +++ b/arch/x86/kernel/rethook.c
> @@ -20,6 +20,7 @@ asm(
>  	".type arch_rethook_trampoline, @function\n"
>  	"arch_rethook_trampoline:\n"
>  #ifdef CONFIG_X86_64
> +	ANNOTATE_NOENDBR
>  	/* Push a fake return address to tell the unwinder it's a kretprobe. */
>  	"	pushq $arch_rethook_trampoline\n"
>  	UNWIND_HINT_FUNC
> @@ -48,7 +49,7 @@ asm(
>  	"	addl $4, %esp\n"
>  	"	popfl\n"
>  #endif
> -	"	ret\n"
> +	ASM_RET
>  	".size arch_rethook_trampoline, .-arch_rethook_trampoline\n"
>  );
>  NOKPROBE_SYMBOL(arch_rethook_trampoline);


-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-22  4:51                           ` Masami Hiramatsu
@ 2022-03-22  4:53                             ` Alexei Starovoitov
  0 siblings, 0 replies; 89+ messages in thread
From: Alexei Starovoitov @ 2022-03-22  4:53 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: Stephen Rothwell, Peter Zijlstra, Daniel Borkmann,
	Andrii Nakryiko, Linus Torvalds, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, Steven Rostedt, Alexei Starovoitov,
	H.J. Lu, Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers, bpf, Networking, David Miller,
	Jakub Kicinski

On Mon, Mar 21, 2022 at 9:51 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> On Mon, 21 Mar 2022 15:50:17 -0700
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > On Mon, Mar 21, 2022 at 3:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi Alexei,
> > >
> > > On Mon, 21 Mar 2022 15:12:05 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > > >
> > > > That makes little sense. It's not an unusual merge conflict.
> > > > Peter's endbr series conflict with Masami's fprobe.
> > > > Peter has a trivial patch that fixes objtool warning.
> > > > The question is how to land that patch.
> > > > I think the best is for Linus to apply it after bpf-next->net-next gets
> > > > merged.
> > >
> > > Peter has other concerns, please read the thread and consider them.
> >
> > Masami is an expert in kprobe. He copy pasted a bit of kprobe logic
> > to make it into 'multi kprobe' (he calls it fprobe).
> > I believe he knows what he's doing.
> > Steven reviewed and tested that set.
> > We've tested it as well and don't have any correctness or api concerns.
>
> Sorry, that's my mistake to not Ccing to arch maintainers for the arch
> dependent patches. Let me update and send v13 for this fprobe series.

No. Please read what I've said earlier.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 22:50                         ` Alexei Starovoitov
  2022-03-21 22:55                           ` Steven Rostedt
@ 2022-03-22  4:51                           ` Masami Hiramatsu
  2022-03-22  4:53                             ` Alexei Starovoitov
  1 sibling, 1 reply; 89+ messages in thread
From: Masami Hiramatsu @ 2022-03-22  4:51 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Stephen Rothwell, Peter Zijlstra, Daniel Borkmann,
	Andrii Nakryiko, Linus Torvalds, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, Masami Hiramatsu, Steven Rostedt,
	Alexei Starovoitov, H.J. Lu, Edgecombe, Rick P, Mike Rapoport,
	linux-toolchains, Andrew Cooper, Nick Desaulniers, bpf,
	Networking, David Miller, Jakub Kicinski

On Mon, 21 Mar 2022 15:50:17 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> On Mon, Mar 21, 2022 at 3:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi Alexei,
> >
> > On Mon, 21 Mar 2022 15:12:05 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > >
> > > That makes little sense. It's not an unusual merge conflict.
> > > Peter's endbr series conflict with Masami's fprobe.
> > > Peter has a trivial patch that fixes objtool warning.
> > > The question is how to land that patch.
> > > I think the best is for Linus to apply it after bpf-next->net-next gets
> > > merged.
> >
> > Peter has other concerns, please read the thread and consider them.
> 
> Masami is an expert in kprobe. He copy pasted a bit of kprobe logic
> to make it into 'multi kprobe' (he calls it fprobe).
> I believe he knows what he's doing.
> Steven reviewed and tested that set.
> We've tested it as well and don't have any correctness or api concerns.

Sorry, that's my mistake to not Ccing to arch maintainers for the arch
dependent patches. Let me update and send v13 for this fprobe series.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 13:45       ` Peter Zijlstra
  2022-03-21 14:19         ` Mark Rutland
  2022-03-21 15:28         ` Peter Zijlstra
@ 2022-03-22  4:38         ` Masami Hiramatsu
  2 siblings, 0 replies; 89+ messages in thread
From: Masami Hiramatsu @ 2022-03-22  4:38 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	rostedt, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Mon, 21 Mar 2022 14:45:16 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > produced these new warnings:
> > > > > 
> > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > 
> > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > those.
> > > 
> > > Ahh, something tracing. I'll go do some patches on top of it.
> > 
> > Also, that x86 patch has never his x86@kernel.org and doesn't have an
> > ACK from any x86 person :-(((
> 
> Worse, it adds a 3rd return trampoline without replacing any of the
> existing two :-(

Sorry about this. I missed to add Ccing to arch maintainers.
Let me check how I can fix those errors.

Thanks.

> 
> Why was this merged?


-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2022-03-22  3:51 Stephen Rothwell
  2022-03-22 21:52 ` Peter Zijlstra
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2022-03-22  3:51 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

WARNING: modpost: EXPORT symbol "device_match_devt" [vmlinux] version ...
Is "device_match_devt" prototyped in <asm/asm-prototypes.h>?

I get thousands like this :-(

I don't know what has done this, but there is a new Kbuild and modpost
change:

  2f35e67f621f ("kbuild: Fixup the IBT kbuild changes")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 22:50                         ` Alexei Starovoitov
@ 2022-03-21 22:55                           ` Steven Rostedt
  2022-03-22  4:51                           ` Masami Hiramatsu
  1 sibling, 0 replies; 89+ messages in thread
From: Steven Rostedt @ 2022-03-21 22:55 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Stephen Rothwell, Peter Zijlstra, Daniel Borkmann,
	Andrii Nakryiko, Linus Torvalds, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux Kernel Mailing List,
	Linux Next Mailing List, Masami Hiramatsu, Alexei Starovoitov,
	H.J. Lu, Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers, bpf, Networking, David Miller,
	Jakub Kicinski

On Mon, 21 Mar 2022 15:50:17 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> > Peter has other concerns, please read the thread and consider them.  
> 
> Masami is an expert in kprobe. He copy pasted a bit of kprobe logic
> to make it into 'multi kprobe' (he calls it fprobe).
> I believe he knows what he's doing.
> Steven reviewed and tested that set.
> We've tested it as well and don't have any correctness or api concerns.

I tested it from a ftrace perspective, not an IBT or other work being done
in the x86 world.

I'm fine with the work being done in kernel/tracing/ but it still requires
the arch maintainer's acks for anything in arch/. I was under the
impression that the arch specific code was Cc'ing the arch maintainers
(which I always do when I touch their code). But I missed that they were
not. That's my fault, I should have caught that.

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 22:46                       ` Stephen Rothwell
@ 2022-03-21 22:50                         ` Alexei Starovoitov
  2022-03-21 22:55                           ` Steven Rostedt
  2022-03-22  4:51                           ` Masami Hiramatsu
  0 siblings, 2 replies; 89+ messages in thread
From: Alexei Starovoitov @ 2022-03-21 22:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Peter Zijlstra, Daniel Borkmann, Andrii Nakryiko, Linus Torvalds,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Steven Rostedt, Alexei Starovoitov, H.J. Lu,
	Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers, bpf, Networking, David Miller,
	Jakub Kicinski

On Mon, Mar 21, 2022 at 3:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Alexei,
>
> On Mon, 21 Mar 2022 15:12:05 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >
> > That makes little sense. It's not an unusual merge conflict.
> > Peter's endbr series conflict with Masami's fprobe.
> > Peter has a trivial patch that fixes objtool warning.
> > The question is how to land that patch.
> > I think the best is for Linus to apply it after bpf-next->net-next gets
> > merged.
>
> Peter has other concerns, please read the thread and consider them.

Masami is an expert in kprobe. He copy pasted a bit of kprobe logic
to make it into 'multi kprobe' (he calls it fprobe).
I believe he knows what he's doing.
Steven reviewed and tested that set.
We've tested it as well and don't have any correctness or api concerns.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 22:12                     ` Alexei Starovoitov
@ 2022-03-21 22:46                       ` Stephen Rothwell
  2022-03-21 22:50                         ` Alexei Starovoitov
  2022-03-22  7:42                       ` Peter Zijlstra
  1 sibling, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2022-03-21 22:46 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Peter Zijlstra, Daniel Borkmann, Andrii Nakryiko, Linus Torvalds,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Steven Rostedt, Alexei Starovoitov, H.J. Lu,
	Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers, bpf, Networking, David Miller,
	Jakub Kicinski

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

Hi Alexei,

On Mon, 21 Mar 2022 15:12:05 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> That makes little sense. It's not an unusual merge conflict.
> Peter's endbr series conflict with Masami's fprobe.
> Peter has a trivial patch that fixes objtool warning.
> The question is how to land that patch.
> I think the best is for Linus to apply it after bpf-next->net-next gets
> merged.

Peter has other concerns, please read the thread and consider them.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 22:05                   ` Stephen Rothwell
@ 2022-03-21 22:12                     ` Alexei Starovoitov
  2022-03-21 22:46                       ` Stephen Rothwell
  2022-03-22  7:42                       ` Peter Zijlstra
  0 siblings, 2 replies; 89+ messages in thread
From: Alexei Starovoitov @ 2022-03-21 22:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Peter Zijlstra, Daniel Borkmann, Andrii Nakryiko, Linus Torvalds,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Steven Rostedt, Alexei Starovoitov, H.J. Lu,
	Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers, bpf, Networking, David Miller,
	Jakub Kicinski

On Mon, Mar 21, 2022 at 3:05 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 21 Mar 2022 09:52:58 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> > On Mon, Mar 21, 2022 at 9:45 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > > >
> > > > It's presumably not in any of the pull requests I already have
> > > > pending, but it would be nice if I saw some details of _what_ you are
> > > > complaining about, and not just the complaint itself ;)
> > >
> > > Duh, right. It's this series:
> > >
> > >   https://lore.kernel.org/bpf/164757541675.26179.17727138330733641017.git-patchwork-notify@kernel.org/
> > >
> > > That went into bpf-next last Friday. I just checked but haven't found a
> > > pull for it yet.
> >
> > Thanks. I can confirm it's not in any of the pull requests I have
> > pending, so I'll just start doing my normal work and try to remember
> > to look out for this issue later.
>
> The normal path for bpf-next code is via the net-next tree.  But the
> above series has not yet been merged into the net-next tree so is only
> in the bpf-next tree.
>
> So, what am I to do?  Drop the bpf-next tree from linux-next until this
> is resolved?  Some input from the BPF people would be useful.
>
> Dave, Jakub, please do not merge the bpf-bext tree into the net-next
> tree for now.

That makes little sense. It's not an unusual merge conflict.
Peter's endbr series conflict with Masami's fprobe.
Peter has a trivial patch that fixes objtool warning.
The question is how to land that patch.
I think the best is for Linus to apply it after bpf-next->net-next gets
merged.

We're preparing bpf-next PR right now.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:52                 ` Linus Torvalds
@ 2022-03-21 22:05                   ` Stephen Rothwell
  2022-03-21 22:12                     ` Alexei Starovoitov
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2022-03-21 22:05 UTC (permalink / raw)
  To: Peter Zijlstra, Daniel Borkmann, Andrii Nakryiko
  Cc: Linus Torvalds, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Steven Rostedt, Alexei Starovoitov, H.J. Lu,
	Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers, bpf, Networking, David Miller,
	Jakub Kicinski

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

Hi all,

On Mon, 21 Mar 2022 09:52:58 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Mon, Mar 21, 2022 at 9:45 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > It's presumably not in any of the pull requests I already have
> > > pending, but it would be nice if I saw some details of _what_ you are
> > > complaining about, and not just the complaint itself ;)  
> >
> > Duh, right. It's this series:
> >
> >   https://lore.kernel.org/bpf/164757541675.26179.17727138330733641017.git-patchwork-notify@kernel.org/
> >
> > That went into bpf-next last Friday. I just checked but haven't found a
> > pull for it yet.  
> 
> Thanks. I can confirm it's not in any of the pull requests I have
> pending, so I'll just start doing my normal work and try to remember
> to look out for this issue later.

The normal path for bpf-next code is via the net-next tree.  But the
above series has not yet been merged into the net-next tree so is only
in the bpf-next tree.

So, what am I to do?  Drop the bpf-next tree from linux-next until this
is resolved?  Some input from the BPF people would be useful.

Dave, Jakub, please do not merge the bpf-bext tree into the net-next
tree for now.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:50                 ` Peter Zijlstra
@ 2022-03-21 16:54                   ` Steven Rostedt
  2022-03-22  7:54                     ` Peter Zijlstra
  0 siblings, 1 reply; 89+ messages in thread
From: Steven Rostedt @ 2022-03-21 16:54 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, 21 Mar 2022 17:50:50 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> > This also assumes that we need to trace everything that is marked. I
> > mentioned in another email, what do we do if we only trace funcA?  
> 
> Like I said later on; if we inhibit tail-calls to notrace, this goes
> away.

Please no. The number of "notrace" functions is increasing to the point
that it's starting to make function tracing useless in a lot of
circumstances. I've already lost my ability to see when user space goes
into the kernel (which I have to hack up custom coding to enable again).

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:44               ` Peter Zijlstra
@ 2022-03-21 16:52                 ` Linus Torvalds
  2022-03-21 22:05                   ` Stephen Rothwell
  0 siblings, 1 reply; 89+ messages in thread
From: Linus Torvalds @ 2022-03-21 16:52 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Steven Rostedt, Alexei Starovoitov, H.J. Lu,
	Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers

On Mon, Mar 21, 2022 at 9:45 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > It's presumably not in any of the pull requests I already have
> > pending, but it would be nice if I saw some details of _what_ you are
> > complaining about, and not just the complaint itself ;)
>
> Duh, right. It's this series:
>
>   https://lore.kernel.org/bpf/164757541675.26179.17727138330733641017.git-patchwork-notify@kernel.org/
>
> That went into bpf-next last Friday. I just checked but haven't found a
> pull for it yet.

Thanks. I can confirm it's not in any of the pull requests I have
pending, so I'll just start doing my normal work and try to remember
to look out for this issue later.

                 Linus

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:45               ` Steven Rostedt
@ 2022-03-21 16:50                 ` Peter Zijlstra
  2022-03-21 16:54                   ` Steven Rostedt
  0 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 16:50 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 12:45:51PM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 17:40:32 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > func_B:
> > 	call __fentry__	/* push func_B */
> > 	...
> > 	call __fexit__	/* pop 1 + tails */
> > 	ret
> > 
> > func_A:
> > 	call __fentry__ /* push func_A */
> > 	...
> > 	call __ftail__  /* mark func_A tail */
> > 	jmp func_B
> > 
> > func_C:
> > 	call __fentry__ /* push func_C */
> > 	call func_A;
> > 	...
> > 	call __fexit__  /* pop 1 + tails */
> > 	ret;
> 
> This also assumes that we need to trace everything that is marked. I
> mentioned in another email, what do we do if we only trace funcA?

Like I said later on; if we inhibit tail-calls to notrace, this goes
away.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 13:04   ` Peter Zijlstra
  2022-03-21 13:08     ` Peter Zijlstra
  2022-03-21 15:28     ` Steven Rostedt
@ 2022-03-21 16:48     ` Peter Zijlstra
  2022-03-22  5:31       ` Masami Hiramatsu
  2 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 16:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	rostedt, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > produced these new warnings:
> > > 
> > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > 
> > Hurmph, lemme go figure out where that code comes from, I've not seen
> > those.
> 
> Ahh, something tracing. I'll go do some patches on top of it.

The below gets rid of the objtool warnings.

But I still think it's fairly terrible to get a (flawed) carbon copy of
the kretprobe code. Also, I think both should fix regs->ss.

---
diff --git a/arch/x86/kernel/rethook.c b/arch/x86/kernel/rethook.c
index f0f2f0608282..227a1890a984 100644
--- a/arch/x86/kernel/rethook.c
+++ b/arch/x86/kernel/rethook.c
@@ -20,6 +20,7 @@ asm(
 	".type arch_rethook_trampoline, @function\n"
 	"arch_rethook_trampoline:\n"
 #ifdef CONFIG_X86_64
+	ANNOTATE_NOENDBR
 	/* Push a fake return address to tell the unwinder it's a kretprobe. */
 	"	pushq $arch_rethook_trampoline\n"
 	UNWIND_HINT_FUNC
@@ -48,7 +49,7 @@ asm(
 	"	addl $4, %esp\n"
 	"	popfl\n"
 #endif
-	"	ret\n"
+	ASM_RET
 	".size arch_rethook_trampoline, .-arch_rethook_trampoline\n"
 );
 NOKPROBE_SYMBOL(arch_rethook_trampoline);

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:40             ` Peter Zijlstra
@ 2022-03-21 16:45               ` Steven Rostedt
  2022-03-21 16:50                 ` Peter Zijlstra
  0 siblings, 1 reply; 89+ messages in thread
From: Steven Rostedt @ 2022-03-21 16:45 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, 21 Mar 2022 17:40:32 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> func_B:
> 	call __fentry__	/* push func_B */
> 	...
> 	call __fexit__	/* pop 1 + tails */
> 	ret
> 
> func_A:
> 	call __fentry__ /* push func_A */
> 	...
> 	call __ftail__  /* mark func_A tail */
> 	jmp func_B
> 
> func_C:
> 	call __fentry__ /* push func_C */
> 	call func_A;
> 	...
> 	call __fexit__  /* pop 1 + tails */
> 	ret;

This also assumes that we need to trace everything that is marked. I
mentioned in another email, what do we do if we only trace funcA?

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:37             ` Linus Torvalds
@ 2022-03-21 16:44               ` Peter Zijlstra
  2022-03-21 16:52                 ` Linus Torvalds
  0 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 16:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Steven Rostedt, Alexei Starovoitov, H.J. Lu,
	Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers

On Mon, Mar 21, 2022 at 09:37:35AM -0700, Linus Torvalds wrote:
> On Mon, Mar 21, 2022 at 8:46 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > This landing in -next only today (after having been committed last
> > friday night) is another clue it should probably go next round.
> 
> I went and looked at lore to get the context that I didn't get in this
> email that I was added to the participants for.
> 
> I didn't find the context there either.
> 
> Sure, I found the thread, but the whole "that x86 patch" that you
> refer to was never actually specified even in the full thread as far
> as I can tell. I see that there is an arm64 equivalent too of what you
> are complaining about, and I have no idea about that one either..
> 
> Mind actually giving the full details so that we don't have to go
> re-do the work you already did?
> 
> Because right now I know something is wrong, I know the warnings, but
> I don't actually have any handle on the actual patches to look out
> for.
> 
> It's presumably not in any of the pull requests I already have
> pending, but it would be nice if I saw some details of _what_ you are
> complaining about, and not just the complaint itself ;)

Duh, right. It's this series:

  https://lore.kernel.org/bpf/164757541675.26179.17727138330733641017.git-patchwork-notify@kernel.org/

That went into bpf-next last Friday. I just checked but haven't found a
pull for it yet.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:15           ` Steven Rostedt
  2022-03-21 16:22             ` Steven Rostedt
@ 2022-03-21 16:40             ` Peter Zijlstra
  2022-03-21 16:45               ` Steven Rostedt
  1 sibling, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 16:40 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 12:15:49PM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 12:12:09 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > > > funcB:
> > > > 	call __fentry__    
> > > 			push funcB on trace-stack  
> > > > 
> > > > 	[..]    
> > > 	call __fexit__
> > > 			pop trace-stack until empty
> > > 			  'exit funcB'
> > > 			  'exit funcA'  
> > 
> > And what happens if funcC called funcA and it too was on the stack. We pop
> > that too? But it's not done yet, because calling of funcA was not a tail
> > call.

Hmm, yeah, how about we have __ftail__ mark the left function.

func_B()
{
	...
}

func_A()
{
	...
	return func_B();
}

func_C()
{
	func_A();
	...
	return;
}

func_B:
	call __fentry__	/* push func_B */
	...
	call __fexit__	/* pop 1 + tails */
	ret

func_A:
	call __fentry__ /* push func_A */
	...
	call __ftail__  /* mark func_A tail */
	jmp func_B

func_C:
	call __fentry__ /* push func_C */
	call func_A;
	...
	call __fexit__  /* pop 1 + tails */
	ret;


Then the stack at the end of func_B looks something like:

	func_C
	func_A (tail)
	func_B

And it will pop func_B plus all tails (func_A).

> And I just thought of another issue, where even my solution wont fix it.
> What happens if we trace funcA but not funcB? How do we get to trace the
> end of funcA?

Disallow tail calls to notrace?

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:22             ` Steven Rostedt
@ 2022-03-21 16:39               ` Steven Rostedt
  0 siblings, 0 replies; 89+ messages in thread
From: Steven Rostedt @ 2022-03-21 16:39 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, 21 Mar 2022 12:22:59 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> Or maybe another solution is:
> 
> funcA:
> 	[..]
> 	jmp funcB
> 	call __fexit__
> 	ret
> 
> And if funcA is being traced, we change jmp to a call.
> 
> 	[..]
> 	call funcB
> 	call __fexit__

We could also make __fexit__ a tail call:

> 	ret


funcA:
	[..]
	call funcB
	jmp __fexit__

We would also need a way to know that funcA has a tail call at the end. So
more help from either the compiler or objtool.

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 15:45           ` Peter Zijlstra
@ 2022-03-21 16:37             ` Linus Torvalds
  2022-03-21 16:44               ` Peter Zijlstra
  0 siblings, 1 reply; 89+ messages in thread
From: Linus Torvalds @ 2022-03-21 16:37 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Steven Rostedt, Alexei Starovoitov, H.J. Lu,
	Edgecombe, Rick P, Mike Rapoport, linux-toolchains,
	Andrew Cooper, Nick Desaulniers

On Mon, Mar 21, 2022 at 8:46 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> This landing in -next only today (after having been committed last
> friday night) is another clue it should probably go next round.

I went and looked at lore to get the context that I didn't get in this
email that I was added to the participants for.

I didn't find the context there either.

Sure, I found the thread, but the whole "that x86 patch" that you
refer to was never actually specified even in the full thread as far
as I can tell. I see that there is an arm64 equivalent too of what you
are complaining about, and I have no idea about that one either..

Mind actually giving the full details so that we don't have to go
re-do the work you already did?

Because right now I know something is wrong, I know the warnings, but
I don't actually have any handle on the actual patches to look out
for.

It's presumably not in any of the pull requests I already have
pending, but it would be nice if I saw some details of _what_ you are
complaining about, and not just the complaint itself ;)

                     Linus

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:15           ` Steven Rostedt
@ 2022-03-21 16:22             ` Steven Rostedt
  2022-03-21 16:39               ` Steven Rostedt
  2022-03-21 16:40             ` Peter Zijlstra
  1 sibling, 1 reply; 89+ messages in thread
From: Steven Rostedt @ 2022-03-21 16:22 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, 21 Mar 2022 12:15:49 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> And I just thought of another issue, where even my solution wont fix it.
> What happens if we trace funcA but not funcB? How do we get to trace the
> end of funcA?

The only solution I can think of to handle all these cases is if you enable
-mfexit, you have to disable tail calls completely. That's going to cause
a performance impact.

Perhaps we need need compiler help to give us a way to hijack the return
address. But is there a way to do this and still not give up the security
that CET SHSTK gives us?

Or maybe another solution is:

funcA:
	[..]
	jmp funcB
	call __fexit__
	ret

And if funcA is being traced, we change jmp to a call.

	[..]
	call funcB
	call __fexit__
	ret

Such that we only remove the tail calls if we enable tracing on the
function with the tail call.

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:12         ` Steven Rostedt
@ 2022-03-21 16:15           ` Steven Rostedt
  2022-03-21 16:22             ` Steven Rostedt
  2022-03-21 16:40             ` Peter Zijlstra
  2022-03-22 14:25           ` Masami Hiramatsu
  1 sibling, 2 replies; 89+ messages in thread
From: Steven Rostedt @ 2022-03-21 16:15 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, 21 Mar 2022 12:12:09 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> > > funcB:
> > > 	call __fentry__    
> > 			push funcB on trace-stack  
> > > 
> > > 	[..]    
> > 	call __fexit__
> > 			pop trace-stack until empty
> > 			  'exit funcB'
> > 			  'exit funcA'  
> 
> And what happens if funcC called funcA and it too was on the stack. We pop
> that too? But it's not done yet, because calling of funcA was not a tail
> call.

And I just thought of another issue, where even my solution wont fix it.
What happens if we trace funcA but not funcB? How do we get to trace the
end of funcA?

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 16:04       ` Peter Zijlstra
@ 2022-03-21 16:12         ` Steven Rostedt
  2022-03-21 16:15           ` Steven Rostedt
  2022-03-22 14:25           ` Masami Hiramatsu
  0 siblings, 2 replies; 89+ messages in thread
From: Steven Rostedt @ 2022-03-21 16:12 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, 21 Mar 2022 17:04:28 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Mar 21, 2022 at 11:28:05AM -0400, Steven Rostedt wrote:
> > On Mon, 21 Mar 2022 14:04:05 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:  
> 
> > > Also, folks, I'm thinking we should start to move to __fexit__, if CET
> > > SHSTK ever wants to come to kernel land return trampolines will
> > > insta-stop working.
> > > 
> > > Hjl, do you think we could get -mfexit to go along with -mfentry ?  
> 
> > int funcA () {
> > 	[..]
> > 	return funcB();
> > }  
> 
> > This currently works with function graph and kretprobe tracing because of
> > the shadow stack. Let's say we traced both funcA and funcB
> > 
> > funcA:
> > 	call __fentry__  
> 			push funcA on trace-stack
> > 
> > 	[..]
> > 	jmp funcB
> > 
> > funcB:
> > 	call __fentry__  
> 			push funcB on trace-stack
> > 
> > 	[..]  
> 	call __fexit__
> 			pop trace-stack until empty
> 			  'exit funcB'
> 			  'exit funcA'

And what happens if funcC called funcA and it too was on the stack. We pop
that too? But it's not done yet, because calling of funcA was not a tail
call.

-- Steve


> 
> > 	ret  
> 
> > 
> > That is, the current algorithm traces the end of both funcA and funcB
> > without issue, because of how the shadow stack works.  
> 
> And it all works, no? Or what am I missing?




^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 15:28     ` Steven Rostedt
@ 2022-03-21 16:04       ` Peter Zijlstra
  2022-03-21 16:12         ` Steven Rostedt
  0 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 16:04 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 11:28:05AM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 14:04:05 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:

> > Also, folks, I'm thinking we should start to move to __fexit__, if CET
> > SHSTK ever wants to come to kernel land return trampolines will
> > insta-stop working.
> > 
> > Hjl, do you think we could get -mfexit to go along with -mfentry ?

> int funcA () {
> 	[..]
> 	return funcB();
> }

> This currently works with function graph and kretprobe tracing because of
> the shadow stack. Let's say we traced both funcA and funcB
> 
> funcA:
> 	call __fentry__
			push funcA on trace-stack
> 
> 	[..]
> 	jmp funcB
> 
> funcB:
> 	call __fentry__
			push funcB on trace-stack
> 
> 	[..]
	call __fexit__
			pop trace-stack until empty
			  'exit funcB'
			  'exit funcA'

> 	ret

> 
> That is, the current algorithm traces the end of both funcA and funcB
> without issue, because of how the shadow stack works.

And it all works, no? Or what am I missing?

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 15:28         ` Peter Zijlstra
@ 2022-03-21 15:45           ` Peter Zijlstra
  2022-03-21 16:37             ` Linus Torvalds
  0 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 15:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	rostedt, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers, Linus Torvalds

On Mon, Mar 21, 2022 at 04:28:06PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:45:16PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > > produced these new warnings:
> > > > > > 
> > > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > 
> > > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > > those.
> > > > 
> > > > Ahh, something tracing. I'll go do some patches on top of it.
> > > 
> > > Also, that x86 patch has never his x86@kernel.org and doesn't have an
> > > ACK from any x86 person :-(((
> > 
> > Worse, it adds a 3rd return trampoline without replacing any of the
> > existing two :-(
> > 
> > Why was this merged?
> 
> It additionally gets ret wrong:
> 
>   vmlinux.o: warning: objtool: arch_rethook_trampoline()+0x4a: missing int3 after ret
> 
> and afaict regs->ss is garbage (much like kretprobes it appears).
> 
> Can we please unmerge this stuff and try again later?

This landing in -next only today (after having been committed last
friday night) is another clue it should probably go next round.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 13:04   ` Peter Zijlstra
  2022-03-21 13:08     ` Peter Zijlstra
@ 2022-03-21 15:28     ` Steven Rostedt
  2022-03-21 16:04       ` Peter Zijlstra
  2022-03-21 16:48     ` Peter Zijlstra
  2 siblings, 1 reply; 89+ messages in thread
From: Steven Rostedt @ 2022-03-21 15:28 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	ast, hjl.tools, rick.p.edgecombe, rppt, linux-toolchains,
	Andrew.Cooper3, ndesaulniers

On Mon, 21 Mar 2022 14:04:05 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> Ahh, something tracing. I'll go do some patches on top of it.
> 
> Also, folks, I'm thinking we should start to move to __fexit__, if CET
> SHSTK ever wants to come to kernel land return trampolines will
> insta-stop working.
> 
> Hjl, do you think we could get -mfexit to go along with -mfentry ?

If we do every add a -mfexit, we will need to add a __ftail__ call.
Because, the current function exit tracing works for functions, even with
tail calls.


int funcA () {
	[..]
	return funcB();
}

Can turn into:

	[..]
	pop all stack from funcA
	load reg params to funcB
	jmp funcB

Then when funcB does does it's

	[..]
	ret

It will pop the call site of funcA (not the call site of funcB) and return
to wherever called funcA with the proper return values.

This currently works with function graph and kretprobe tracing because of
the shadow stack. Let's say we traced both funcA and funcB

funcA:
	call __fentry__

			Replace caller address with graph_trampoline and
			store the return caller into the shadow stack.

	[..]
	jmp funcB

funcB:
	call __fentry__

			Replace caller address with graph_trampoline and
			store the return caller (which is the
			graph_trampoline that was switched earlier) in the
			shadow stack.

	[..]
	ret

			Returns to the graph_trampoline and we trace the
			return of funcB. Then we pop off the shadow stack
			and jump to that. But the shadow stack had a call
			to the graph_trampoline, which gets called again.

			Returns to the graph_trampoline and we trace the
			return of funcA. Then we pop off the shadow stack
			and jump to that, which is the original caller to
			funcA.

That is, the current algorithm traces the end of both funcA and funcB
without issue, because of how the shadow stack works.

Now if we add a __fexit__, we will need a way to tell the tracers how to
record this scenario. That is why I'm thinking of a jmp to __ftail__.

Perhaps something like:

funcA:
	call __fentry__
	[..]
	push address of funcB
	jmp __ftail__
	jmp funcB

Where, __ftail__ would do at the end:

	ret

To jump to funcB and we skip the jmp to funcB anyway.

And to "nop" it out, we would have to convert it to.

funcA:
	call __fentry__
	[..]
	jmp 1
	jmp __ftail__
1:	jmp funcB


This is one way I can think of if we include a __fexit__. But to maintain
backward compatibility to function graph tracing (which is a requirement),
we need to be able to handle such cases.

Perhaps this is a good topic to bring up at Plumbers? :-)

Do I need to submit a tracing MC, or can we have this conversation at a
compiler / toolchain MC?

-- Steve

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 13:45       ` Peter Zijlstra
  2022-03-21 14:19         ` Mark Rutland
@ 2022-03-21 15:28         ` Peter Zijlstra
  2022-03-21 15:45           ` Peter Zijlstra
  2022-03-22  4:38         ` Masami Hiramatsu
  2 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 15:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	rostedt, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 02:45:16PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > produced these new warnings:
> > > > > 
> > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > 
> > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > those.
> > > 
> > > Ahh, something tracing. I'll go do some patches on top of it.
> > 
> > Also, that x86 patch has never his x86@kernel.org and doesn't have an
> > ACK from any x86 person :-(((
> 
> Worse, it adds a 3rd return trampoline without replacing any of the
> existing two :-(
> 
> Why was this merged?

It additionally gets ret wrong:

  vmlinux.o: warning: objtool: arch_rethook_trampoline()+0x4a: missing int3 after ret

and afaict regs->ss is garbage (much like kretprobes it appears).

Can we please unmerge this stuff and try again later?

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 13:45       ` Peter Zijlstra
@ 2022-03-21 14:19         ` Mark Rutland
  2022-03-21 15:28         ` Peter Zijlstra
  2022-03-22  4:38         ` Masami Hiramatsu
  2 siblings, 0 replies; 89+ messages in thread
From: Mark Rutland @ 2022-03-21 14:19 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	rostedt, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 02:45:16PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > produced these new warnings:
> > > > > 
> > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > 
> > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > those.
> > > 
> > > Ahh, something tracing. I'll go do some patches on top of it.
> > 
> > Also, that x86 patch has never his x86@kernel.org and doesn't have an
> > ACK from any x86 person :-(((
> 
> Worse, it adds a 3rd return trampoline without replacing any of the
> existing two :-(

Likewise; I have the same complaints for the arm64 patch.

I haven't had the chance to review/ack that, and I'm actively working on
improving out unwinder and the way it interacts with the various *existing*
trampolines, so adding yat another is *not* good.

> Why was this merged?

Likewise, same question for arm64?

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 13:08     ` Peter Zijlstra
@ 2022-03-21 13:45       ` Peter Zijlstra
  2022-03-21 14:19         ` Mark Rutland
                           ` (2 more replies)
  0 siblings, 3 replies; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 13:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	rostedt, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > produced these new warnings:
> > > > 
> > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > 
> > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > those.
> > 
> > Ahh, something tracing. I'll go do some patches on top of it.
> 
> Also, that x86 patch has never his x86@kernel.org and doesn't have an
> ACK from any x86 person :-(((

Worse, it adds a 3rd return trampoline without replacing any of the
existing two :-(

Why was this merged?

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 13:04   ` Peter Zijlstra
@ 2022-03-21 13:08     ` Peter Zijlstra
  2022-03-21 13:45       ` Peter Zijlstra
  2022-03-21 15:28     ` Steven Rostedt
  2022-03-21 16:48     ` Peter Zijlstra
  2 siblings, 1 reply; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 13:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	rostedt, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > produced these new warnings:
> > > 
> > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > 
> > Hurmph, lemme go figure out where that code comes from, I've not seen
> > those.
> 
> Ahh, something tracing. I'll go do some patches on top of it.

Also, that x86 patch has never his x86@kernel.org and doesn't have an
ACK from any x86 person :-(((

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21 12:55 ` Peter Zijlstra
@ 2022-03-21 13:04   ` Peter Zijlstra
  2022-03-21 13:08     ` Peter Zijlstra
                       ` (2 more replies)
  2022-03-22 10:46   ` Peter Zijlstra
  1 sibling, 3 replies; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 13:04 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List, mhiramat,
	rostedt, ast, hjl.tools, rick.p.edgecombe, rppt,
	linux-toolchains, Andrew.Cooper3, ndesaulniers

On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > produced these new warnings:
> > 
> > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> 
> Hurmph, lemme go figure out where that code comes from, I've not seen
> those.

Ahh, something tracing. I'll go do some patches on top of it.

Also, folks, I'm thinking we should start to move to __fexit__, if CET
SHSTK ever wants to come to kernel land return trampolines will
insta-stop working.

Hjl, do you think we could get -mfexit to go along with -mfentry ?

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-03-21  3:03 Stephen Rothwell
@ 2022-03-21 12:55 ` Peter Zijlstra
  2022-03-21 13:04   ` Peter Zijlstra
  2022-03-22 10:46   ` Peter Zijlstra
  0 siblings, 2 replies; 89+ messages in thread
From: Peter Zijlstra @ 2022-03-21 12:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List

On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x864 allmodconfig)
> produced these new warnings:
> 
> vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0

Hurmph, lemme go figure out where that code comes from, I've not seen
those.

> [ Note I was already getting these:
> arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()

Yes, those are somewhere on the todo list, lemme bump them.

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2022-03-21  3:03 Stephen Rothwell
  2022-03-21 12:55 ` Peter Zijlstra
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2022-03-21  3:03 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x864 allmodconfig)
produced these new warnings:

vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0

[ Note I was already getting these:
arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
]

I have no idea what has caused this ...

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2022-01-21 23:58 ` Stephen Rothwell
@ 2022-03-15  2:32   ` Stephen Rothwell
  2022-04-04  3:26     ` Stephen Rothwell
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2022-03-15  2:32 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 2935 bytes --]

Hi all,

On Sat, 22 Jan 2022 10:58:06 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Fri, 17 Dec 2021 14:40:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > produced these warnings:
> > 
> > lib/strnlen_user.o: warning: objtool: strnlen_user()+0xc9: call to do_strnlen_user() with UACCESS enabled
> > lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x129: call to do_strncpy_from_user() with UACCESS enabled
> > vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section
> > 
> > I am not sure which changes caused the above.  
> 
> I currently still get the following warnings from an x86_64
> allmodconfig build fo Linus' tree:
> 
> vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
> vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section
> 
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 11.2.0-9) 11.2.0
> $ x86_64-linux-gnu-ld --version
> GNU ld (GNU Binutils for Debian) 2.37

I gained these new ones after merging today's tip tree:

arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx512() falls through to next function poly1305_blocks_x86_64()

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2021-12-17  3:40 Stephen Rothwell
@ 2022-01-21 23:58 ` Stephen Rothwell
  2022-03-15  2:32   ` Stephen Rothwell
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2022-01-21 23:58 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

Hi all,

On Fri, 17 Dec 2021 14:40:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
> 
> lib/strnlen_user.o: warning: objtool: strnlen_user()+0xc9: call to do_strnlen_user() with UACCESS enabled
> lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x129: call to do_strncpy_from_user() with UACCESS enabled
> vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
> vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section
> 
> I am not sure which changes caused the above.

I currently still get the following warnings from an x86_64
allmodconfig build fo Linus' tree:

vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section

$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 11.2.0-9) 11.2.0
$ x86_64-linux-gnu-ld --version
GNU ld (GNU Binutils for Debian) 2.37

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2021-12-17  3:40 Stephen Rothwell
  2022-01-21 23:58 ` Stephen Rothwell
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2021-12-17  3:40 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

lib/strnlen_user.o: warning: objtool: strnlen_user()+0xc9: call to do_strnlen_user() with UACCESS enabled
lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x129: call to do_strncpy_from_user() with UACCESS enabled
vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section

I am not sure which changes caused the above.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2021-10-12 10:20 Stephen Rothwell
@ 2021-10-12 13:58 ` André Almeida
  0 siblings, 0 replies; 89+ messages in thread
From: André Almeida @ 2021-10-12 13:58 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

Hi Stephen,

Às 07:20 de 12/10/21, Stephen Rothwell escreveu:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (htmldocs) produced
> these warnings:
> 
> Error: Cannot open file kernel/futex.c
> Error: Cannot open file kernel/futex.c
> Error: Cannot open file kernel/futex.c
> Error: Cannot open file kernel/futex.c
> 
> Introduced by commit
> 
>   77e52ae35463 ("futex: Move to kernel/futex/")
> 
> $ git grep kernel/futex Documentation
> Documentation/kernel-hacking/locking.rst:.. kernel-doc:: kernel/futex.c
> Documentation/translations/it_IT/kernel-hacking/locking.rst:.. kernel-doc:: kernel/futex.c
> 

Thanks for pointing that out. I posted a fix:

https://lore.kernel.org/lkml/20211012135549.14451-1-andrealmeid@collabora.com/

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2021-10-12 10:20 Stephen Rothwell
  2021-10-12 13:58 ` André Almeida
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2021-10-12 10:20 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: André Almeida, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Error: Cannot open file kernel/futex.c
Error: Cannot open file kernel/futex.c
Error: Cannot open file kernel/futex.c
Error: Cannot open file kernel/futex.c

Introduced by commit

  77e52ae35463 ("futex: Move to kernel/futex/")

$ git grep kernel/futex Documentation
Documentation/kernel-hacking/locking.rst:.. kernel-doc:: kernel/futex.c
Documentation/translations/it_IT/kernel-hacking/locking.rst:.. kernel-doc:: kernel/futex.c

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2020-11-30 21:56   ` Ernst, Justin
@ 2020-11-30 22:18     ` Borislav Petkov
  0 siblings, 0 replies; 89+ messages in thread
From: Borislav Petkov @ 2020-11-30 22:18 UTC (permalink / raw)
  To: Ernst, Justin
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Kernel Mailing List,
	Linux Next Mailing List, Travis, Mike

On Mon, Nov 30, 2020 at 09:56:27PM +0000, Ernst, Justin wrote:
> After scratching my head for a while, I found that the issue was
> missing empty lines before three different code-block sections.

Oh great.

> The line number is definitely bogus, but I wasn't able to discover
> why.

Very helpful that tool. :-\

> You can find my patch at: https://lkml.org/lkml/2020/11/30/1196 The
> patch depends on the v2 patch set Mike Travis <mike.travis@hpe.com>
> submitted, which hasn't made it to tip yet.

Yeah, thanks for figuring this out.

I'll simply rebase your previous patch on the tip:x86/platform branch
since it is documentation stuff only and there's only one patch ontop
which updates MAINTAINERS but I don't think it'll be the end of the
world if those two got rebased.

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 89+ messages in thread

* RE: linux-next: build warnings after merge of the tip tree
  2020-11-30 10:17 ` Borislav Petkov
@ 2020-11-30 21:56   ` Ernst, Justin
  2020-11-30 22:18     ` Borislav Petkov
  0 siblings, 1 reply; 89+ messages in thread
From: Ernst, Justin @ 2020-11-30 21:56 UTC (permalink / raw)
  To: Borislav Petkov, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List, Travis, Mike

> On Mon, Nov 30, 2020 at 06:05:03PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (htmldocs) produced
> > these warnings:
> >
> > Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> > Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> > Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> >
> > Introduced by commit
> >
> >   7ac2f1017115 ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")
> 
> Yah, I can reproduce but I have no clue what sphinx wants from me. Line
> 2 looks ok which could mean that the warning line it points to is bogus.
> 
> Justin, this is all yours. :)

After scratching my head for a while, I found that the issue was missing empty lines before three different code-block sections.
The line number is definitely bogus, but I wasn't able to discover why.

You can find my patch at: https://lkml.org/lkml/2020/11/30/1196
The patch depends on the v2 patch set Mike Travis <mike.travis@hpe.com> submitted, which hasn't made it to tip yet.

Thanks,
-Justin

> 
> Thx.
> 
> --
> Regards/Gruss,
>     Boris.
> 
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2020-11-30  7:05 Stephen Rothwell
@ 2020-11-30 10:17 ` Borislav Petkov
  2020-11-30 21:56   ` Ernst, Justin
  0 siblings, 1 reply; 89+ messages in thread
From: Borislav Petkov @ 2020-11-30 10:17 UTC (permalink / raw)
  To: Stephen Rothwell, Justin Ernst
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

On Mon, Nov 30, 2020 at 06:05:03PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (htmldocs) produced
> these warnings:
> 
> Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> 
> Introduced by commit
> 
>   7ac2f1017115 ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")

Yah, I can reproduce but I have no clue what sphinx wants from me. Line
2 looks ok which could mean that the warning line it points to is bogus.

Justin, this is all yours. :)

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2020-11-30  7:05 Stephen Rothwell
  2020-11-30 10:17 ` Borislav Petkov
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2020-11-30  7:05 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Justin Ernst, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.

Introduced by commit

  7ac2f1017115 ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2020-11-23  7:19 Stephen Rothwell
@ 2020-11-23 23:03 ` Jarkko Sakkinen
  0 siblings, 0 replies; 89+ messages in thread
From: Jarkko Sakkinen @ 2020-11-23 23:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Borislav Petkov, Linux Kernel Mailing List,
	Linux Next Mailing List

On Mon, Nov 23, 2020 at 06:19:22PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (htmldocs) produced
> these warnings:
> 
> arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Function parameter or member 'encl' not described in 'sgx_ioc_enclave_provision'
> arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Excess function parameter 'enclave' description in 'sgx_ioc_enclave_provision'
> 
> Introduced by commit
> 
>   c82c61865024 ("x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION")
> 
> -- 
> Cheers,
> Stephen Rothwell

Thanks, was about sending a fix but saw that Boris put already one out,
when adding "Link: https://lore.kernel.org/linux-next/20201123101334.GC29678@zn.tnic/"

/Jarkko

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2020-11-23  7:19 Stephen Rothwell
  2020-11-23 23:03 ` Jarkko Sakkinen
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2020-11-23  7:19 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Jarkko Sakkinen, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Function parameter or member 'encl' not described in 'sgx_ioc_enclave_provision'
arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Excess function parameter 'enclave' description in 'sgx_ioc_enclave_provision'

Introduced by commit

  c82c61865024 ("x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2017-11-02  2:53 Stephen Rothwell
  2017-11-03 21:00 ` Masami Hiramatsu
@ 2017-11-13 11:31 ` Stephen Rothwell
  1 sibling, 0 replies; 89+ messages in thread
From: Stephen Rothwell @ 2017-11-13 11:31 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Masami Hiramatsu

Hi all,

On Thu, 2 Nov 2017 13:53:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
> 
> net/dccp/probe.c: In function 'dccpprobe_init':
> net/dccp/probe.c:166:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   ret = register_jprobe(&dccp_send_probe);
>   ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/dccp/probe.c:170:4: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>     ret = register_jprobe(&dccp_send_probe);
>     ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/dccp/probe.c: In function 'dccpprobe_exit':
> net/dccp/probe.c:190:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&dccp_send_probe);
>   ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> net/ipv4/tcp_probe.c: In function 'tcpprobe_init':
> net/ipv4/tcp_probe.c:280:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   ret = register_jprobe(&tcp_jprobe);
>   ^
> In file included from net/ipv4/tcp_probe.c:24:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/ipv4/tcp_probe.c: In function 'tcpprobe_exit':
> net/ipv4/tcp_probe.c:298:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&tcp_jprobe);
>   ^
> In file included from net/ipv4/tcp_probe.c:24:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> net/sctp/probe.c: In function 'sctp_setup_jprobe':
> net/sctp/probe.c:189:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   int ret = register_jprobe(&sctp_recv_probe);
>   ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/sctp/probe.c:194:3: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>    ret = register_jprobe(&sctp_recv_probe);
>    ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/sctp/probe.c: In function 'sctpprobe_exit':
> net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&sctp_recv_probe);
>   ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> 
> Introduced by commit
> 
>   590c84593045 ("kprobes: Disable the jprobes APIs")
> 
> These days we normally don't deprecate things, just remove them.  But we
> do that *after* fixing up all the usages in the tree, please.

Just a reminder that I am still getting these warnings.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2017-11-04  8:01   ` Ingo Molnar
@ 2017-11-04 12:16     ` Masami Hiramatsu
  0 siblings, 0 replies; 89+ messages in thread
From: Masami Hiramatsu @ 2017-11-04 12:16 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Sat, 4 Nov 2017 09:01:34 +0100
Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > > net/sctp/probe.c: In function 'sctpprobe_exit':
> > > net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
> > >   unregister_jprobe(&sctp_recv_probe);
> > >   ^
> > > In file included from net/sctp/probe.c:28:0:
> > > include/linux/kprobes.h:479:33: note: declared here
> > >  static inline void __deprecated unregister_jprobe(struct jprobe *p)
> > >                                  ^
> > > 
> > > Introduced by commit
> > > 
> > >   590c84593045 ("kprobes: Disable the jprobes APIs")
> > > 
> > > These days we normally don't deprecate things, just remove them.  But we
> > > do that *after* fixing up all the usages in the tree, please.
> > 
> > OK, should I remove __deprecated or revert above patch?
> > I pinged such users but no response. I can just rewrite it but not sure they can reply.
> 
> Ideal would be to just fix all these places: convert code where the facility 
> appears to be actively used, remove code where it looks unused. If maintainers 
> don't reply, I can apply them to a separate branch in -tip.

Thanks, that will help me.

> 
> For example I'm pretty sure we can just remove the jprobes usage in SCTP.

Actually TCP and DCCP jprobes usages are similar to that SCTP usage 
(maybe derived from TCP one). For those usages, we can not replace
it with kprobe/ftrace because it depends on the arguments of target funcs.
For such use-cases, we have 3 options;
 - Remove entirely feature if possible (like no more used).
 - Replace it with trace-events, and handle the event from kernel as sched tracer does.
 - Just introduce trace-events, remove usage, and trace it via ftrace or perf.

At a glance, all network probes are just used for printing out the event,
so we can just introduce trace-events and remove usage. I will try it.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2017-11-03 21:00 ` Masami Hiramatsu
@ 2017-11-04  8:01   ` Ingo Molnar
  2017-11-04 12:16     ` Masami Hiramatsu
  0 siblings, 1 reply; 89+ messages in thread
From: Ingo Molnar @ 2017-11-04  8:01 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List


* Masami Hiramatsu <mhiramat@kernel.org> wrote:

> > net/sctp/probe.c: In function 'sctpprobe_exit':
> > net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
> >   unregister_jprobe(&sctp_recv_probe);
> >   ^
> > In file included from net/sctp/probe.c:28:0:
> > include/linux/kprobes.h:479:33: note: declared here
> >  static inline void __deprecated unregister_jprobe(struct jprobe *p)
> >                                  ^
> > 
> > Introduced by commit
> > 
> >   590c84593045 ("kprobes: Disable the jprobes APIs")
> > 
> > These days we normally don't deprecate things, just remove them.  But we
> > do that *after* fixing up all the usages in the tree, please.
> 
> OK, should I remove __deprecated or revert above patch?
> I pinged such users but no response. I can just rewrite it but not sure they can reply.

Ideal would be to just fix all these places: convert code where the facility 
appears to be actively used, remove code where it looks unused. If maintainers 
don't reply, I can apply them to a separate branch in -tip.

For example I'm pretty sure we can just remove the jprobes usage in SCTP.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2017-11-02  2:53 Stephen Rothwell
@ 2017-11-03 21:00 ` Masami Hiramatsu
  2017-11-04  8:01   ` Ingo Molnar
  2017-11-13 11:31 ` Stephen Rothwell
  1 sibling, 1 reply; 89+ messages in thread
From: Masami Hiramatsu @ 2017-11-03 21:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Masami Hiramatsu

On Thu, 2 Nov 2017 13:53:51 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
> 
> net/dccp/probe.c: In function 'dccpprobe_init':
> net/dccp/probe.c:166:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   ret = register_jprobe(&dccp_send_probe);
>   ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/dccp/probe.c:170:4: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>     ret = register_jprobe(&dccp_send_probe);
>     ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/dccp/probe.c: In function 'dccpprobe_exit':
> net/dccp/probe.c:190:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&dccp_send_probe);
>   ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> net/ipv4/tcp_probe.c: In function 'tcpprobe_init':
> net/ipv4/tcp_probe.c:280:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   ret = register_jprobe(&tcp_jprobe);
>   ^
> In file included from net/ipv4/tcp_probe.c:24:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/ipv4/tcp_probe.c: In function 'tcpprobe_exit':
> net/ipv4/tcp_probe.c:298:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&tcp_jprobe);
>   ^
> In file included from net/ipv4/tcp_probe.c:24:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> net/sctp/probe.c: In function 'sctp_setup_jprobe':
> net/sctp/probe.c:189:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   int ret = register_jprobe(&sctp_recv_probe);
>   ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/sctp/probe.c:194:3: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>    ret = register_jprobe(&sctp_recv_probe);
>    ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/sctp/probe.c: In function 'sctpprobe_exit':
> net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&sctp_recv_probe);
>   ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> 
> Introduced by commit
> 
>   590c84593045 ("kprobes: Disable the jprobes APIs")
> 
> These days we normally don't deprecate things, just remove them.  But we
> do that *after* fixing up all the usages in the tree, please.

OK, should I remove __deprecated or revert above patch?
I pinged such users but no response. I can just rewrite it but not sure they can reply.

Thank you,

> 
> -- 
> Cheers,
> Stephen Rothwell


-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2017-11-02  2:53 Stephen Rothwell
  2017-11-03 21:00 ` Masami Hiramatsu
  2017-11-13 11:31 ` Stephen Rothwell
  0 siblings, 2 replies; 89+ messages in thread
From: Stephen Rothwell @ 2017-11-02  2:53 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Masami Hiramatsu

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

net/dccp/probe.c: In function 'dccpprobe_init':
net/dccp/probe.c:166:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
  ret = register_jprobe(&dccp_send_probe);
  ^
In file included from net/dccp/probe.c:26:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/dccp/probe.c:170:4: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
    ret = register_jprobe(&dccp_send_probe);
    ^
In file included from net/dccp/probe.c:26:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/dccp/probe.c: In function 'dccpprobe_exit':
net/dccp/probe.c:190:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
  unregister_jprobe(&dccp_send_probe);
  ^
In file included from net/dccp/probe.c:26:0:
include/linux/kprobes.h:479:33: note: declared here
 static inline void __deprecated unregister_jprobe(struct jprobe *p)
                                 ^
net/ipv4/tcp_probe.c: In function 'tcpprobe_init':
net/ipv4/tcp_probe.c:280:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
  ret = register_jprobe(&tcp_jprobe);
  ^
In file included from net/ipv4/tcp_probe.c:24:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/ipv4/tcp_probe.c: In function 'tcpprobe_exit':
net/ipv4/tcp_probe.c:298:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
  unregister_jprobe(&tcp_jprobe);
  ^
In file included from net/ipv4/tcp_probe.c:24:0:
include/linux/kprobes.h:479:33: note: declared here
 static inline void __deprecated unregister_jprobe(struct jprobe *p)
                                 ^
net/sctp/probe.c: In function 'sctp_setup_jprobe':
net/sctp/probe.c:189:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
  int ret = register_jprobe(&sctp_recv_probe);
  ^
In file included from net/sctp/probe.c:28:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/sctp/probe.c:194:3: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
   ret = register_jprobe(&sctp_recv_probe);
   ^
In file included from net/sctp/probe.c:28:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/sctp/probe.c: In function 'sctpprobe_exit':
net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
  unregister_jprobe(&sctp_recv_probe);
  ^
In file included from net/sctp/probe.c:28:0:
include/linux/kprobes.h:479:33: note: declared here
 static inline void __deprecated unregister_jprobe(struct jprobe *p)
                                 ^

Introduced by commit

  590c84593045 ("kprobes: Disable the jprobes APIs")

These days we normally don't deprecate things, just remove them.  But we
do that *after* fixing up all the usages in the tree, please.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2017-06-23  4:19 Stephen Rothwell
  0 siblings, 0 replies; 89+ messages in thread
From: Stephen Rothwell @ 2017-06-23  4:19 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

In file included from arch/x86/include/asm/paravirt_types.h:44:0,
                 from arch/x86/include/asm/ptrace.h:71,
                 from arch/x86/include/asm/math_emu.h:4,
                 from arch/x86/include/asm/processor.h:11,
                 from arch/x86/include/asm/cpufeature.h:4,
                 from arch/x86/include/asm/thread_info.h:52,
                 from include/linux/thread_info.h:37,
                 from arch/x86/include/asm/preempt.h:6,
                 from include/linux/preempt.h:80,
                 from include/linux/spinlock.h:50,
                 from include/linux/seqlock.h:35,
                 from include/linux/time.h:5,
                 from include/uapi/linux/timex.h:56,
                 from include/linux/timex.h:56,
                 from include/linux/clocksource.h:12,
                 from arch/x86/include/asm/vgtod.h:5,
                 from arch/x86/entry/vdso/vdso32/../vclock_gettime.c:15,
                 from arch/x86/entry/vdso/vdso32/vclock_gettime.c:32:
arch/x86/include/asm/pgtable.h: In function 'pte_flags_pkey':
arch/x86/include/asm/pgtable_types.h:56:43: warning: left shift count >= width of type [-Wshift-count-overflow]
 #define _PAGE_PKEY_BIT0 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT0)
                                           ^
arch/x86/include/asm/pgtable_types.h:68:26: note: in expansion of macro '_PAGE_PKEY_BIT0'
 #define _PAGE_PKEY_MASK (_PAGE_PKEY_BIT0 | \
                          ^
arch/x86/include/asm/pgtable.h:1187:22: note: in expansion of macro '_PAGE_PKEY_MASK'
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                      ^
arch/x86/include/asm/pgtable_types.h:57:43: warning: left shift count >= width of type [-Wshift-count-overflow]
 #define _PAGE_PKEY_BIT1 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT1)
                                           ^
arch/x86/include/asm/pgtable_types.h:69:5: note: in expansion of macro '_PAGE_PKEY_BIT1'
     _PAGE_PKEY_BIT1 | \
     ^
arch/x86/include/asm/pgtable.h:1187:22: note: in expansion of macro '_PAGE_PKEY_MASK'
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                      ^
arch/x86/include/asm/pgtable_types.h:58:43: warning: left shift count >= width of type [-Wshift-count-overflow]
 #define _PAGE_PKEY_BIT2 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT2)
                                           ^
arch/x86/include/asm/pgtable_types.h:70:5: note: in expansion of macro '_PAGE_PKEY_BIT2'
     _PAGE_PKEY_BIT2 | \
     ^
arch/x86/include/asm/pgtable.h:1187:22: note: in expansion of macro '_PAGE_PKEY_MASK'
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                      ^
arch/x86/include/asm/pgtable_types.h:59:43: warning: left shift count >= width of type [-Wshift-count-overflow]
 #define _PAGE_PKEY_BIT3 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT3)
                                           ^
arch/x86/include/asm/pgtable_types.h:71:5: note: in expansion of macro '_PAGE_PKEY_BIT3'
     _PAGE_PKEY_BIT3)
     ^
arch/x86/include/asm/pgtable.h:1187:22: note: in expansion of macro '_PAGE_PKEY_MASK'
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                      ^
In file included from include/linux/kasan.h:16:0,
                 from include/linux/slab.h:120,
                 from include/linux/irq.h:25,
                 from arch/x86/include/asm/hardirq.h:5,
                 from include/linux/hardirq.h:8,
                 from include/linux/interrupt.h:12,
                 from arch/x86/include/asm/mshyperv.h:5,
                 from arch/x86/entry/vdso/vdso32/../vclock_gettime.c:20,
                 from arch/x86/entry/vdso/vdso32/vclock_gettime.c:32:
arch/x86/include/asm/pgtable.h:1187:39: warning: right shift count >= width of type [-Wshift-count-overflow]
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                                       ^

I have no idea what caused this.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 89+ messages in thread

* Re: linux-next: build warnings after merge of the tip tree
  2016-07-14  3:37 Stephen Rothwell
@ 2016-07-14  4:18 ` Stephen Rothwell
  0 siblings, 0 replies; 89+ messages in thread
From: Stephen Rothwell @ 2016-07-14  4:18 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo

Hi all,

On Thu, 14 Jul 2016 13:37:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (powerpc64le perf)
> produced these warnings:
> 
> Warning: tools/include/uapi/linux/bpf.h differs from kernel
> Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
> Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
> Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel
> 
> Introduced by commits
> 
>   7d7d1bf1d1da ("perf bench: Copy kernel files needed to build mem{cpy,set} x86_64 benchmarks")
>   971e827bffef ("tools lib bpf: Copy bpf.h and bpf_common.h from the kernel")

The kvm tree has introduced a few more:

Warning: tools/arch/s390/include/uapi/asm/kvm.h
Warning: tools/arch/s390/include/uapi/asm/sie.h

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2016-07-14  3:49 Stephen Rothwell
  0 siblings, 0 replies; 89+ messages in thread
From: Stephen Rothwell @ 2016-07-14  3:49 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

In file included from tools/include/linux/hashtable.h:12:0,
                 from elf.h:24,
                 from builtin-check.c:33:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from elf.h:23,
                 from builtin-check.c:33:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the previous definition
 #define BITS_PER_LONG 32
 ^
In file included from tools/include/linux/hashtable.h:12:0,
                 from elf.h:24,
                 from special.h:22,
                 from special.c:26:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from elf.h:23,
                 from special.h:22,
                 from special.c:26:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the previous definition
 #define BITS_PER_LONG 32
 ^
In file included from tools/include/linux/hashtable.h:12:0,
                 from elf.h:24,
                 from elf.c:30:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from elf.h:23,
                 from elf.c:30:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the previous definition
 #define BITS_PER_LONG 32
 ^
cc1: all warnings being treated as errors
In file included from tools/include/linux/hashtable.h:12:0,
                 from arch/x86/../../elf.h:24,
                 from arch/x86/decode.c:26:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from arch/x86/../../elf.h:23,
                 from arch/x86/decode.c:26:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the previous definition
 #define BITS_PER_LONG 32
 ^

Introduced (I think) by commit

  bb9707077b4e ("tools: Copy the bitsperlong.h files from the kernel")

I saw some discussion of this, so I assume ti will be fixed soon.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2016-07-14  3:37 Stephen Rothwell
  2016-07-14  4:18 ` Stephen Rothwell
  0 siblings, 1 reply; 89+ messages in thread
From: Stephen Rothwell @ 2016-07-14  3:37 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo

Hi all,

After merging the tip tree, today's linux-next build (powerpc64le perf)
produced these warnings:

Warning: tools/include/uapi/linux/bpf.h differs from kernel
Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel

Introduced by commits

  7d7d1bf1d1da ("perf bench: Copy kernel files needed to build mem{cpy,set} x86_64 benchmarks")
  971e827bffef ("tools lib bpf: Copy bpf.h and bpf_common.h from the kernel")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 89+ messages in thread

* linux-next: build warnings after merge of the tip tree
@ 2012-10-12  5:11 Stephen Rothwell
  0 siblings, 0 replies; 89+ messages in thread
From: Stephen Rothwell @ 2012-10-12  5:11 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc allnoconfig)
produced these warnings:

kernel/sched/fair.c:801:22: warning: 'task_h_load' declared 'static' but never defined [-Wunused-function]
kernel/sched/fair.c:1013:13: warning: 'account_offnode_enqueue' defined but not used [-Wunused-function]

Introduced by commit 4ae834f767c5 ("sched/numa: Implement NUMA home-node
selection code").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 89+ messages in thread

end of thread, other threads:[~2022-11-21  7:42 UTC | newest]

Thread overview: 89+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-31  4:27 linux-next: build warnings after merge of the tip tree Stephen Rothwell
2011-01-31  5:08 ` Jaswinder Singh
2011-01-31 19:12   ` [PATCH] Fix linux-next warning from abb74cef Venkatesh Pallipadi
2011-01-31 19:38     ` Randy Dunlap
2011-01-31 20:16       ` Venkatesh Pallipadi
2011-01-31 20:25         ` Randy Dunlap
2012-10-12  5:11 linux-next: build warnings after merge of the tip tree Stephen Rothwell
2016-07-14  3:37 Stephen Rothwell
2016-07-14  4:18 ` Stephen Rothwell
2016-07-14  3:49 Stephen Rothwell
2017-06-23  4:19 Stephen Rothwell
2017-11-02  2:53 Stephen Rothwell
2017-11-03 21:00 ` Masami Hiramatsu
2017-11-04  8:01   ` Ingo Molnar
2017-11-04 12:16     ` Masami Hiramatsu
2017-11-13 11:31 ` Stephen Rothwell
2020-11-23  7:19 Stephen Rothwell
2020-11-23 23:03 ` Jarkko Sakkinen
2020-11-30  7:05 Stephen Rothwell
2020-11-30 10:17 ` Borislav Petkov
2020-11-30 21:56   ` Ernst, Justin
2020-11-30 22:18     ` Borislav Petkov
2021-10-12 10:20 Stephen Rothwell
2021-10-12 13:58 ` André Almeida
2021-12-17  3:40 Stephen Rothwell
2022-01-21 23:58 ` Stephen Rothwell
2022-03-15  2:32   ` Stephen Rothwell
2022-04-04  3:26     ` Stephen Rothwell
2022-03-21  3:03 Stephen Rothwell
2022-03-21 12:55 ` Peter Zijlstra
2022-03-21 13:04   ` Peter Zijlstra
2022-03-21 13:08     ` Peter Zijlstra
2022-03-21 13:45       ` Peter Zijlstra
2022-03-21 14:19         ` Mark Rutland
2022-03-21 15:28         ` Peter Zijlstra
2022-03-21 15:45           ` Peter Zijlstra
2022-03-21 16:37             ` Linus Torvalds
2022-03-21 16:44               ` Peter Zijlstra
2022-03-21 16:52                 ` Linus Torvalds
2022-03-21 22:05                   ` Stephen Rothwell
2022-03-21 22:12                     ` Alexei Starovoitov
2022-03-21 22:46                       ` Stephen Rothwell
2022-03-21 22:50                         ` Alexei Starovoitov
2022-03-21 22:55                           ` Steven Rostedt
2022-03-22  4:51                           ` Masami Hiramatsu
2022-03-22  4:53                             ` Alexei Starovoitov
2022-03-22  7:42                       ` Peter Zijlstra
2022-03-22  4:38         ` Masami Hiramatsu
2022-03-21 15:28     ` Steven Rostedt
2022-03-21 16:04       ` Peter Zijlstra
2022-03-21 16:12         ` Steven Rostedt
2022-03-21 16:15           ` Steven Rostedt
2022-03-21 16:22             ` Steven Rostedt
2022-03-21 16:39               ` Steven Rostedt
2022-03-21 16:40             ` Peter Zijlstra
2022-03-21 16:45               ` Steven Rostedt
2022-03-21 16:50                 ` Peter Zijlstra
2022-03-21 16:54                   ` Steven Rostedt
2022-03-22  7:54                     ` Peter Zijlstra
2022-03-22 13:12                       ` Steven Rostedt
2022-03-22 14:35                         ` Peter Zijlstra
2022-03-22 15:04                           ` Steven Rostedt
2022-03-22 15:19                             ` Peter Zijlstra
2022-03-22 15:48                             ` Peter Zijlstra
2022-03-22 16:17                               ` Steven Rostedt
2022-03-23  2:23                           ` Masami Hiramatsu
2022-03-23  2:42                             ` Steven Rostedt
2022-03-23  6:28                               ` Masami Hiramatsu
2022-03-22 14:25           ` Masami Hiramatsu
2022-03-21 16:48     ` Peter Zijlstra
2022-03-22  5:31       ` Masami Hiramatsu
2022-03-22  8:08         ` Peter Zijlstra
2022-03-22  9:14           ` Masami Hiramatsu
2022-03-22 12:07             ` Peter Zijlstra
2022-03-22 12:17         ` Peter Zijlstra
2022-03-22 12:46           ` Masami Hiramatsu
2022-03-22 13:22             ` Steven Rostedt
2022-03-22 13:15         ` Mark Rutland
2022-03-22 13:51           ` Masami Hiramatsu
2022-03-22 10:46   ` Peter Zijlstra
2022-03-22 10:59     ` Peter Zijlstra
2022-03-22  3:51 Stephen Rothwell
2022-03-22 21:52 ` Peter Zijlstra
2022-03-22 23:11   ` Stephen Rothwell
2022-04-27  0:10 Stephen Rothwell
2022-04-27 11:31 ` Borislav Petkov
2022-04-27 13:43   ` Tom Lendacky
2022-05-20  7:49 Stephen Rothwell
2022-11-21  7:41 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).