Re: [GIT pull] objtool/core for v5.16-rc1

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Nov 01, 2021 at 01:44:39PM -0700, Linus Torvalds wrote:
> On Sun, Oct 31, 2021 at 6:16 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > please pull the latest objtool/core branch from:
> 
> Hmm. I've pulled this, but I'm not happy about the new warnings it
> generates with an allmodconfig build:

Right, due to fixing the dependency on !PARAVIRT, allyesconfig now does
a noinstr validation, and this is the result.

>   vmlinux.o: warning: objtool: __do_fast_syscall_32()+0xa: call to
> stackleak_track_stack() leaves .noinstr.text section
>    ..
>     mce_setup()+0x18: call to memset ...

Boris was having a poke at the MCE stuff.

>     rcu_dynticks_eqs_enter()+0x0: call to rcu_dynticks_task_trace_enter ...
>     rcu_dynticks_eqs_exit()+0xe: call to rcu_dynticks_task_trace_exit ...
>     rcu_nmi_enter()+0x36: call to __kasan_check_read ...

Fixes for those ^ should be in the rcu tree.

There were also a bunch of Xen ones that should be fixed in the Xen
tree, perhaps you've already pulled that.

>     do_machine_check()+0x27: call to stackleak_track_stack ...
>     do_syscall_64()+0x9: call to stackleak_track_stack ...
>     do_int80_syscall_32()+0x9: call to stackleak_track_stack ...
>     exc_general_protection()+0x22: call to stackleak_track_stack ...
>     fixup_bad_iret()+0x20: call to stackleak_track_stack ...
>     .entry.text+0x10e6: call to stackleak_erase ...
>     .entry.text+0x143: call to stackleak_erase ...
>     .entry.text+0x17d9: call to stackleak_erase ...
> 
> most seem to be about the stackleak thing,

Right, I recently ran into this and hacen't yet had time to look into
it. I suspect my normal build box doesn't have the GCC plugin crud
enabled or somesuch.

I think the GCC stackleak plugin needs fixing, specifically it needs a
function attribute such that it will not emit instrumentation in noinstr
functions. I'll go chase down the developer of that thing.