Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 2 Nov 2021 09:00:36 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [GIT pull] objtool/core for v5.16-rc1
Message-ID: <YYDwJORywW2FjprP@hirez.programming.kicks-ass.net>
References: <163572864256.3357115.931779940195622047.tglx@xen13>
 <163572864563.3357115.8793939214537874196.tglx@xen13>
 <CAHk-=wgNzL3AaVNruwLv=kcGXi1EbJN9CZC6GoRY66t6WFcfGg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wgNzL3AaVNruwLv=kcGXi1EbJN9CZC6GoRY66t6WFcfGg@mail.gmail.com>
Precedence: bulk

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.