linux-next: new objtool warnings

linux-next: new objtool warnings

[Stephen Rothwell]

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

Hi all,

My x86_64 allmodconfig builds started producing these warnings today:

vmlinux.o: warning: objtool: user_exc_vmm_communication+0x15a: call to __kasan_check_read() leaves .noinstr.text section
vmlinux.o: warning: objtool: exc_debug_user+0x182: call to __kasan_check_read() leaves .noinstr.text section
vmlinux.o: warning: objtool: exc_int3+0x123: call to __kasan_check_read() leaves .noinstr.text section
vmlinux.o: warning: objtool: noist_exc_machine_check+0x17a: call to __kasan_check_read() leaves .noinstr.text section
vmlinux.o: warning: objtool: fred_exc_machine_check+0x17e: call to __kasan_check_read() leaves .noinstr.text section

I can't easily tell what caused this change, sorry.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: new objtool warnings

[Peter Zijlstra]

On Fri, Oct 31, 2025 at 11:15:15AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> My x86_64 allmodconfig builds started producing these warnings today:
> 
> vmlinux.o: warning: objtool: user_exc_vmm_communication+0x15a: call to __kasan_check_read() leaves .noinstr.text section
> vmlinux.o: warning: objtool: exc_debug_user+0x182: call to __kasan_check_read() leaves .noinstr.text section
> vmlinux.o: warning: objtool: exc_int3+0x123: call to __kasan_check_read() leaves .noinstr.text section
> vmlinux.o: warning: objtool: noist_exc_machine_check+0x17a: call to __kasan_check_read() leaves .noinstr.text section
> vmlinux.o: warning: objtool: fred_exc_machine_check+0x17e: call to __kasan_check_read() leaves .noinstr.text section
> 
> I can't easily tell what caused this change, sorry.

What compiler? This smells like a broken compiler, these are all
noinstr and that very much has __no_sanitize_address.

Re: linux-next: new objtool warnings

[Stephen Rothwell]

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

Hi Peter,

On Mon, 3 Nov 2025 10:10:06 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, Oct 31, 2025 at 11:15:15AM +1100, Stephen Rothwell wrote:
> > 
> > My x86_64 allmodconfig builds started producing these warnings today:
> > 
> > vmlinux.o: warning: objtool: user_exc_vmm_communication+0x15a: call to __kasan_check_read() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: exc_debug_user+0x182: call to __kasan_check_read() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: exc_int3+0x123: call to __kasan_check_read() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: noist_exc_machine_check+0x17a: call to __kasan_check_read() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: fred_exc_machine_check+0x17e: call to __kasan_check_read() leaves .noinstr.text section
> > 
> > I can't easily tell what caused this change, sorry.  
> 
> What compiler? This smells like a broken compiler, these are all
> noinstr and that very much has __no_sanitize_address.

And today I didn't get them.  So who knows?  I did *not* change compiler
since Friday.

$ /usr/bin/x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0

Cross compiler hosted on ppc64 le.
-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: new objtool warnings

[Peter Zijlstra]

On Mon, Nov 03, 2025 at 08:32:56PM +1100, Stephen Rothwell wrote:
> Hi Peter,
> 
> On Mon, 3 Nov 2025 10:10:06 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Fri, Oct 31, 2025 at 11:15:15AM +1100, Stephen Rothwell wrote:
> > > 
> > > My x86_64 allmodconfig builds started producing these warnings today:
> > > 
> > > vmlinux.o: warning: objtool: user_exc_vmm_communication+0x15a: call to __kasan_check_read() leaves .noinstr.text section
> > > vmlinux.o: warning: objtool: exc_debug_user+0x182: call to __kasan_check_read() leaves .noinstr.text section
> > > vmlinux.o: warning: objtool: exc_int3+0x123: call to __kasan_check_read() leaves .noinstr.text section
> > > vmlinux.o: warning: objtool: noist_exc_machine_check+0x17a: call to __kasan_check_read() leaves .noinstr.text section
> > > vmlinux.o: warning: objtool: fred_exc_machine_check+0x17e: call to __kasan_check_read() leaves .noinstr.text section
> > > 
> > > I can't easily tell what caused this change, sorry.  
> > 
> > What compiler? This smells like a broken compiler, these are all
> > noinstr and that very much has __no_sanitize_address.
> 
> And today I didn't get them.  So who knows?  I did *not* change compiler
> since Friday.

Oh well, lets chalk it up to gremlins for now. I'll have a look if it
happens again/reliably.

Re: linux-next: new objtool warnings

[Stephen Rothwell]

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

Hi Peter,

On Mon, 3 Nov 2025 10:38:04 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Nov 03, 2025 at 08:32:56PM +1100, Stephen Rothwell wrote:
> > 
> > On Mon, 3 Nov 2025 10:10:06 +0100 Peter Zijlstra <peterz@infradead.org> wrote:  
> > >
> > > On Fri, Oct 31, 2025 at 11:15:15AM +1100, Stephen Rothwell wrote:  
> > > > 
> > > > My x86_64 allmodconfig builds started producing these warnings today:
> > > > 
> > > > vmlinux.o: warning: objtool: user_exc_vmm_communication+0x15a: call to __kasan_check_read() leaves .noinstr.text section
> > > > vmlinux.o: warning: objtool: exc_debug_user+0x182: call to __kasan_check_read() leaves .noinstr.text section
> > > > vmlinux.o: warning: objtool: exc_int3+0x123: call to __kasan_check_read() leaves .noinstr.text section
> > > > vmlinux.o: warning: objtool: noist_exc_machine_check+0x17a: call to __kasan_check_read() leaves .noinstr.text section
> > > > vmlinux.o: warning: objtool: fred_exc_machine_check+0x17e: call to __kasan_check_read() leaves .noinstr.text section
> > > > 
> > > > I can't easily tell what caused this change, sorry.    
> > > 
> > > What compiler? This smells like a broken compiler, these are all
> > > noinstr and that very much has __no_sanitize_address.  
> > 
> > And today I didn't get them.  So who knows?  I did *not* change compiler
> > since Friday.  
> 
> Oh well, lets chalk it up to gremlins for now. I'll have a look if it
> happens again/reliably.

These objtool messages have returned today.  No change in compiler.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: new objtool warnings

[Peter Zijlstra]

On Wed, Nov 05, 2025 at 02:30:27PM +1100, Stephen Rothwell wrote:

> These objtool messages have returned today.  No change in compiler.

Yes, Ingo also reported them on IRC, let me go investigate!

Re: linux-next: new objtool warnings

[Peter Zijlstra]

On Wed, Nov 05, 2025 at 09:56:37AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 05, 2025 at 02:30:27PM +1100, Stephen Rothwell wrote:
> 
> > These objtool messages have returned today.  No change in compiler.
> 
> Yes, Ingo also reported them on IRC, let me go investigate!

The below cures things, but I'm not quite sure why they show up now and
not before. Let me poke more.

---
diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h
index 72e3f7a59469..6ab913e57da0 100644
--- a/include/linux/irq-entry-common.h
+++ b/include/linux/irq-entry-common.h
@@ -293,11 +293,11 @@ static __always_inline void irqentry_exit_to_user_mode_prepare(struct pt_regs *r
 static __always_inline void exit_to_user_mode(void)
 {
 	instrumentation_begin();
+	unwind_reset_info();
 	trace_hardirqs_on_prepare();
 	lockdep_hardirqs_on_prepare();
 	instrumentation_end();
 
-	unwind_reset_info();
 	user_enter_irqoff();
 	arch_exit_to_user_mode();
 	lockdep_hardirqs_on(CALLER_ADDR0);

Re: linux-next: new objtool warnings

[Peter Zijlstra]

On Wed, Nov 05, 2025 at 11:00:14AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 05, 2025 at 09:56:37AM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 05, 2025 at 02:30:27PM +1100, Stephen Rothwell wrote:
> > 
> > > These objtool messages have returned today.  No change in compiler.
> > 
> > Yes, Ingo also reported them on IRC, let me go investigate!
> 
> The below cures things, but I'm not quite sure why they show up now and
> not before. Let me poke more.

Also, someone wrecked the build system.

vmlinux.o is no longer a valid build target, and the vmlinux target
seems to build a ton of module stuff :/

Re: linux-next: new objtool warnings

[Peter Zijlstra]

+ Nathan

On Wed, Nov 05, 2025 at 11:02:02AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 05, 2025 at 11:00:14AM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 05, 2025 at 09:56:37AM +0100, Peter Zijlstra wrote:
> > > On Wed, Nov 05, 2025 at 02:30:27PM +1100, Stephen Rothwell wrote:
> > > 
> > > > These objtool messages have returned today.  No change in compiler.
> > > 
> > > Yes, Ingo also reported them on IRC, let me go investigate!
> > 
> > The below cures things, but I'm not quite sure why they show up now and
> > not before. Let me poke more.
> 
> Also, someone wrecked the build system.
> 
> vmlinux.o is no longer a valid build target, and the vmlinux target
> seems to build a ton of module stuff :/

Re: linux-next: new objtool warnings

[Nathan Chancellor]

Hey Peter,

On Wed, Nov 05, 2025 at 11:10:10AM +0100, Peter Zijlstra wrote:
> + Nathan

Thanks for the heads up.

> On Wed, Nov 05, 2025 at 11:02:02AM +0100, Peter Zijlstra wrote:
> > Also, someone wrecked the build system.
> > 
> > vmlinux.o is no longer a valid build target, and the vmlinux target
> > seems to build a ton of module stuff :/

I tested the major stable releases (6.1, 6.6, and 6.12), long before
Nicolas and I took over Kbuild, and vmlinux.o does not work as a target
in any of them:

  $ make -skj"$(nproc)" ARCH=x86_64 mrproper
  $ make -skj"$(nproc)" ARCH=x86_64 defconfig
  $ make -skj"$(nproc)" ARCH=x86_64 vmlinux.o
  Makefile:1912: warning: overriding recipe for target 'vmlinux.o'
  Makefile:1150: warning: ignoring old recipe for target 'vmlinux.o'
  make[2]: *** No rule to make target 'vmlinux.o'.

When did this work? Is it configuration dependent? FWIW, it looks like
the 'vmlinux_o' targets does the right thing? I am not sure why it
exists instead of just vmlinux.o, Masahiro did that in commit
7a342e6c7735 ("kbuild: move modules.builtin(.modinfo) rules to
Makefile.vmlinux_o") in 6.1.

As for the second comment, if I build the vmlinux target, I see:

  AR      built-in.a
  AR      vmlinux.a
  LD      vmlinux.o
  MODPOST vmlinux.symvers
  CC      .vmlinux.export.o
  UPD     include/generated/utsversion.h
  CC      init/version-timestamp.o
  KSYMS   .tmp_vmlinux0.kallsyms.S
  AS      .tmp_vmlinux0.kallsyms.o
  LD      .tmp_vmlinux1
  NM      .tmp_vmlinux1.syms
  KSYMS   .tmp_vmlinux1.kallsyms.S
  AS      .tmp_vmlinux1.kallsyms.o
  LD      .tmp_vmlinux2
  NM      .tmp_vmlinux2.syms
  KSYMS   .tmp_vmlinux2.kallsyms.S
  AS      .tmp_vmlinux2.kallsyms.o
  LD      vmlinux.unstripped
  NM      System.map
  SORTTAB vmlinux.unstripped
  OBJCOPY vmlinux
  OBJCOPY modules.builtin.modinfo
  GEN     modules.builtin

at the end of the build with no instances of [M]. What "ton of module
stuff" are you seeing in your build? Also configuration dependent?

Cheers,
Nathan

Re: linux-next: new objtool warnings

[Peter Zijlstra]

On Wed, Nov 05, 2025 at 10:07:15AM -0700, Nathan Chancellor wrote:

>   $ make -skj"$(nproc)" ARCH=x86_64 vmlinux.o
>   Makefile:1912: warning: overriding recipe for target 'vmlinux.o'
>   Makefile:1150: warning: ignoring old recipe for target 'vmlinux.o'
>   make[2]: *** No rule to make target 'vmlinux.o'.
> 
> When did this work? 

Dunno, I have vague memories of it working. The only reason I tried
is that vmlinux seems to be misbehaving.

> As for the second comment, if I build the vmlinux target, I see:
> 
>   AR      built-in.a
>   AR      vmlinux.a
>   LD      vmlinux.o
>   MODPOST vmlinux.symvers
>   CC      .vmlinux.export.o
>   UPD     include/generated/utsversion.h
>   CC      init/version-timestamp.o
>   KSYMS   .tmp_vmlinux0.kallsyms.S
>   AS      .tmp_vmlinux0.kallsyms.o
>   LD      .tmp_vmlinux1
>   NM      .tmp_vmlinux1.syms
>   KSYMS   .tmp_vmlinux1.kallsyms.S
>   AS      .tmp_vmlinux1.kallsyms.o
>   LD      .tmp_vmlinux2
>   NM      .tmp_vmlinux2.syms
>   KSYMS   .tmp_vmlinux2.kallsyms.S
>   AS      .tmp_vmlinux2.kallsyms.o
>   LD      vmlinux.unstripped
>   NM      System.map
>   SORTTAB vmlinux.unstripped
>   OBJCOPY vmlinux
>   OBJCOPY modules.builtin.modinfo
>   GEN     modules.builtin

# make O=tmp-build clean
# make O=tmp-build allmodconfig
# make O=tmp-build -j64 vmlinux 2>&1 | grep "\[M\]"
  CC [M]  sound/sound_core.o
  CC [M]  virt/lib/irqbypass.o
  AS [M]  arch/x86/crypto/twofish-x86_64-asm_64.o
  CC [M]  arch/x86/crypto/twofish_glue.o
  CC [M]  samples/vfio-mdev/mtty.o
  CC [M]  sound/ac97_bus.o
  AS [M]  arch/x86/crypto/twofish-x86_64-asm_64-3way.o
  CC [M]  arch/x86/crypto/twofish_glue_3way.o

Re: linux-next: new objtool warnings

[Nathan Chancellor]

On Wed, Nov 05, 2025 at 08:16:13PM +0100, Peter Zijlstra wrote:
> # make O=tmp-build clean
> # make O=tmp-build allmodconfig
> # make O=tmp-build -j64 vmlinux 2>&1 | grep "\[M\]"
>   CC [M]  sound/sound_core.o
>   CC [M]  virt/lib/irqbypass.o
>   AS [M]  arch/x86/crypto/twofish-x86_64-asm_64.o
>   CC [M]  arch/x86/crypto/twofish_glue.o
>   CC [M]  samples/vfio-mdev/mtty.o
>   CC [M]  sound/ac97_bus.o
>   AS [M]  arch/x86/crypto/twofish-x86_64-asm_64-3way.o
>   CC [M]  arch/x86/crypto/twofish_glue_3way.o

Thanks, I bisected this to commit d2d5cba5d92c ("kbuild: remove EXPERT
and !COMPILE_TEST guarding from TRIM_UNUSED_KSYMS"), which explains
everything when looking at Makefile:

  ifdef CONFIG_TRIM_UNUSED_KSYMS
  # For the kernel to actually contain only the needed exported symbols,
  # we have to build modules as well to determine what those symbols are.
  KBUILD_MODULES := y
  endif

Maybe we want to restore the !COMPILE_TEST dependency?

Cheers,
Nathan

Re: linux-next: new objtool warnings

[Peter Zijlstra]

On Wed, Nov 05, 2025 at 01:09:23PM -0700, Nathan Chancellor wrote:
> On Wed, Nov 05, 2025 at 08:16:13PM +0100, Peter Zijlstra wrote:
> > # make O=tmp-build clean
> > # make O=tmp-build allmodconfig
> > # make O=tmp-build -j64 vmlinux 2>&1 | grep "\[M\]"
> >   CC [M]  sound/sound_core.o
> >   CC [M]  virt/lib/irqbypass.o
> >   AS [M]  arch/x86/crypto/twofish-x86_64-asm_64.o
> >   CC [M]  arch/x86/crypto/twofish_glue.o
> >   CC [M]  samples/vfio-mdev/mtty.o
> >   CC [M]  sound/ac97_bus.o
> >   AS [M]  arch/x86/crypto/twofish-x86_64-asm_64-3way.o
> >   CC [M]  arch/x86/crypto/twofish_glue_3way.o
> 
> Thanks, I bisected this to commit d2d5cba5d92c ("kbuild: remove EXPERT
> and !COMPILE_TEST guarding from TRIM_UNUSED_KSYMS"), which explains
> everything when looking at Makefile:
> 
>   ifdef CONFIG_TRIM_UNUSED_KSYMS
>   # For the kernel to actually contain only the needed exported symbols,
>   # we have to build modules as well to determine what those symbols are.
>   KBUILD_MODULES := y
>   endif
> 
> Maybe we want to restore the !COMPILE_TEST dependency?

Urgh, yeah, I suppose we do want. This TRIM_UNUSED_KSYMS is cute if you
swing that way for a full build, but getting all modules built if you
just want a vmlinux is really somewhat unexpected.

[tip: perf/core] entry,unwind/deferred: Fix unwind_reset_info() placement

[tip-bot2 for Peter Zijlstra]

The following commit has been merged into the perf/core branch of tip:

Commit-ID:     cf76553aaa363620f58a6b6409bf544f4bcfa8de
Gitweb:        https://git.kernel.org/tip/cf76553aaa363620f58a6b6409bf544f4bcfa8de
Author:        Peter Zijlstra <peterz@infradead.org>
AuthorDate:    Wed, 05 Nov 2025 11:00:14 +01:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Wed, 05 Nov 2025 13:57:32 +01:00

entry,unwind/deferred: Fix unwind_reset_info() placement

Stephen reported that on KASAN builds he's seeing:

vmlinux.o: warning: objtool: user_exc_vmm_communication+0x15a: call to __kasan_check_read() leaves .noinstr.text section
vmlinux.o: warning: objtool: exc_debug_user+0x182: call to __kasan_check_read() leaves .noinstr.text section
vmlinux.o: warning: objtool: exc_int3+0x123: call to __kasan_check_read() leaves .noinstr.text section
vmlinux.o: warning: objtool: noist_exc_machine_check+0x17a: call to __kasan_check_read() leaves .noinstr.text section
vmlinux.o: warning: objtool: fred_exc_machine_check+0x17e: call to __kasan_check_read() leaves .noinstr.text section

This turns out to be atomic ops from unwind_reset_info() that have
explicit instrumentation. Place unwind_reset_info() in the preceding
instrumentation_begin() section.

Fixes: c6439bfaabf2 ("Merge tag 'trace-deferred-unwind-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20251105100014.GY4068168@noisy.programming.kicks-ass.net
---
 include/linux/irq-entry-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h
index d643c7c..ba1ed42 100644
--- a/include/linux/irq-entry-common.h
+++ b/include/linux/irq-entry-common.h
@@ -253,11 +253,11 @@ static __always_inline void exit_to_user_mode_prepare(struct pt_regs *regs)
 static __always_inline void exit_to_user_mode(void)
 {
 	instrumentation_begin();
+	unwind_reset_info();
 	trace_hardirqs_on_prepare();
 	lockdep_hardirqs_on_prepare();
 	instrumentation_end();
 
-	unwind_reset_info();
 	user_enter_irqoff();
 	arch_exit_to_user_mode();
 	lockdep_hardirqs_on(CALLER_ADDR0);