[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOdnd2X+m9YhOqXbw912BW2vP-RtFusch3_fughriqvruaw@mail.gmail.com>
Date: Tue, 7 Feb 2023 09:50:16 -0800
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
Josh Poimboeuf <jpoimboe@...nel.org>
Subject: Re: current objtool warnings from randconfig builds
On Tue, Feb 7, 2023 at 9:42 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> On Tue, Feb 07, 2023 at 05:16:58PM +0100, Peter Zijlstra wrote:
> > On Tue, Feb 07, 2023 at 11:25:27AM +0100, Arnd Bergmann wrote:
> > > Hi Josh and Peter,
> > >
> > > I've updated my randconfig test setup to use gcc-13 and clang-16, and
> > > have sent fixes for all normal WERROR=y build warnings, but there are a
> > > lot of objtool warnings that remain. I've reported some of them in
> > > the past, some others are new. It would be nice to at least reduce
> > > the number of warnings either through code changes or workarounds
> > > in objtool for any false positives.
> > >
> > > Out of 1500 builds, about a third had any warnings, this is the full
> > > list sorted by frequency. Let me know if there are any that you haven't
> > > seen before, I can provide the corresponding object and config files
> > > for reproducing.
> > >
> > > Arnd
> > >
> > > 8<---
> > > 205 mm/kasan/shadow.o: warning: objtool: __asan_memset+0x2e: call to __memset() with UACCESS enabled
> > > 205 mm/kasan/shadow.o: warning: objtool: __asan_memmove+0x48: call to __memmove() with UACCESS enabled
> > > 205 mm/kasan/shadow.o: warning: objtool: __asan_memcpy+0x48: call to __memcpy() with UACCESS enabled
> >
> > Patch pending here:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=sched/core-robot&id=79cdfdacd5b8d1ac77e24ccbc178bba0294d0d78
> > 
> >
> > > 80 vmlinux.o: warning: objtool: ibt_selftest+0x11: sibling call from callable instruction with modified stack frame
> >
> > Can you provide details on how to reproduce this?
>
> Arnd, thanks for rounding these up and posting them.
>
> I agree we need to get these all cleaned up, but before we go too far
> down the rabbit hole, is there some better way to track these?
>
> Not that I would suggest using an external tracker, but maybe at least
> put each set of related warnings (e.g., those having the same frequency)
> in its own subthread with the config/compiler info included.
If any are specific to clang, please use
https://github.com/ClangBuiltLinux/linux/issues
We have a tag for issues flagged by objtool
https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aopen+is%3Aissue+label%3A%22%5BTOOL%5D+objtool%22
>
> --
> Josh
>
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists