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;
MIME-Version: 1.0
References: <163572864256.3357115.931779940195622047.tglx@xen13> <163572864563.3357115.8793939214537874196.tglx@xen13>
In-Reply-To: <163572864563.3357115.8793939214537874196.tglx@xen13>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 1 Nov 2021 13:44:39 -0700
Message-ID: <CAHk-=wgNzL3AaVNruwLv=kcGXi1EbJN9CZC6GoRY66t6WFcfGg@mail.gmail.com>
Subject: Re: [GIT pull] objtool/core for v5.16-rc1
To:     Thomas Gleixner <tglx@linutronix.de>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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:

  vmlinux.o: warning: objtool: __do_fast_syscall_32()+0xa: call to
stackleak_track_stack() leaves .noinstr.text section
   ..
    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 ...
    mce_setup()+0x18: call to memset ...
    do_machine_check()+0x27: call to stackleak_track_stack ...
    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 ...
    .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, but there's a memset in
there too, and rcu_dynticks_task_trace_enter/exit and
__kasan_check_read..

It may be compiler-dependent, this is with F34 and gcc 11.2.1 20210728.

With my actual normal config (and clang), I don't see any of these,
but that's not only a different compiler, it's a much smaller config
that has no kasan/stackleak etc.

                  Linus