[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201022072553.GN2628@hirez.programming.kicks-ass.net>
Date: Thu, 22 Oct 2020 09:25:53 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Sami Tolvanen <samitolvanen@...gle.com>,
Jann Horn <jannh@...gle.com>,
the arch/x86 maintainers <x86@...nel.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Will Deacon <will@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Kees Cook <keescook@...omium.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
linux-arch <linux-arch@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-kbuild <linux-kbuild@...r.kernel.org>,
kernel list <linux-kernel@...r.kernel.org>,
linux-pci@...r.kernel.org
Subject: Re: [PATCH v6 22/25] x86/asm: annotate indirect jumps
On Wed, Oct 21, 2020 at 04:27:47PM -0500, Josh Poimboeuf wrote:
> On Wed, Oct 21, 2020 at 11:32:13AM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 21, 2020 at 10:56:06AM +0200, Peter Zijlstra wrote:
> >
> > > I do not see these in particular, although I do see a lot of:
> > >
> > > "sibling call from callable instruction with modified stack frame"
> >
> > defconfig-build/vmlinux.o: warning: objtool: msr_write()+0x10a: sibling call from callable instruction with modified stack frame
> > defconfig-build/vmlinux.o: warning: objtool: msr_write()+0x99: (branch)
> > defconfig-build/vmlinux.o: warning: objtool: msr_write()+0x3e: (branch)
> > defconfig-build/vmlinux.o: warning: objtool: msr_write()+0x0: <=== (sym)
> >
> > $ nm defconfig-build/vmlinux.o | grep msr_write
> > 0000000000043250 t msr_write
> > 00000000004289c0 T msr_write
> > 0000000000003056 t msr_write.cold
> >
> > Below 'fixes' it. So this is also caused by duplicate symbols.
>
> There's a new linker flag for renaming duplicates:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=26391
>
> But I guess that doesn't help us now.
Well, depends a bit if clang can do it; we only need this for LTO builds
for now.
> I don't have access to GCC 10 at the moment so I can't recreate it.
> Does this fix it?
Doesn't seem to do the trick :/ I'll try and have a poke later.
Powered by blists - more mailing lists