[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230207174227.rimpkz3b3y7m4fch@treble>
Date: Tue, 7 Feb 2023 09:42:27 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: current objtool warnings from randconfig builds
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.
--
Josh
Powered by blists - more mailing lists