[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2ATzqRSqVeeKNswLU74+bjvwK_GmG0=jbMymVaSp2ysw@mail.gmail.com>
Date: Wed, 28 Aug 2019 17:28:50 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
Ilie Halip <ilie.halip@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: objtool warning "uses BP as a scratch register" with clang-9
On Wed, Aug 28, 2019 at 5:22 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> On Wed, Aug 28, 2019 at 05:13:59PM +0200, Arnd Bergmann wrote:
> > On Wed, Aug 28, 2019 at 11:00 AM Arnd Bergmann <arnd@...db.de> wrote:
> > > On Tue, Aug 27, 2019 at 11:22 PM 'Nick Desaulniers' via Clang Built Linux <clang-built-linux@...glegroups.com> wrote:
> > I figured this one out as well:
> >
> > > http://paste.ubuntu.com/p/XjdDsypRxX/
> > > 0x5BA1B7A1:arch/x86/ia32/ia32_signal.o: warning: objtool:
> > > ia32_setup_rt_frame()+0x238: call to memset() with UACCESS enabled
> > > 0x5BA1B7A1:arch/x86/kernel/signal.o: warning: objtool:
> > > __setup_rt_frame()+0x5b8: call to memset() with UACCESS enabled
> >
> > When CONFIG_KASAN is set, clang decides to use memset() to set
> > the first two struct members in this function:
> >
> > static inline void sas_ss_reset(struct task_struct *p)
> > {
> > p->sas_ss_sp = 0;
> > p->sas_ss_size = 0;
> > p->sas_ss_flags = SS_DISABLE;
> > }
> >
> > and that is called from save_altstack_ex(). Adding a barrier() after
> > the sas_ss_sp() works around the issue, but is certainly not the
> > best solution. Any other ideas?
>
> Wow, is the compiler allowed to insert memset calls like that? Seems a
> bit overbearing, at least in a kernel context. I don't recall GCC ever
> doing it.
Yes, it's free to assume that any standard library function behaves
as defined, so it can and will turn struct assignments into memcpy
or back, or replace string operations with others depending on what
seems better for optimization.
clang is more aggressive than gcc here, and this has caused some
other problems in the past, but it's usually harmless.
In theory, we could pass -ffreestanding to tell the compiler
not to make assumptions about standard library function behavior,
but that turns off all kinds of useful optimizations. The problem
is really that the kernel is neither exactly hosted nor freestanding.
Arnd
Powered by blists - more mailing lists