[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YjpLiKRUIB4TGJm0@zn.tnic>
Date: Tue, 22 Mar 2022 23:19:52 +0100
From: Borislav Petkov <bp@...en8.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>,
Boqun Feng <boqun.feng@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [GIT PULL] locking changes for v5.18
+ Sebastian.
On Tue, Mar 22, 2022 at 03:05:39PM -0700, Linus Torvalds wrote:
> On Mon, Mar 21, 2022 at 4:11 AM Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Sebastian Andrzej Siewior (2):
> > locking/local_lock: Make the empty local_lock_*() function a macro.
>
> Grr. I noticed this too late, but this one actually breaks the build with clang.
>
> Why?
>
> Because it's now a macro, it doesn't use the argument at all, and you get:
>
> mm/page_alloc.c:131:40: error: variable 'pagesets' is not needed
> and will not be emitted [-Werror,-Wunneeded-internal-declaration]
> static DEFINE_PER_CPU(struct pagesets, pagesets) = {
> ^
>
> and I'm not sure why this doesn't show up with gcc, but apparently gcc
> only warns about unused static functions, not unused static data.
>
> Or maybe gcc considers it used just because somebody did a typeof on it.
>
> I thought -tip had started checking with clang, but apparently not.
As a matter of fact, I do see this in my builds:
mm/page_alloc.c:131:40: warning: variable 'pagesets' is not needed and will not be emitted [-Wunneeded-internal-declaration]
static DEFINE_PER_CPU(struct pagesets, pagesets) = {
^
1 warning generated.
but I dismissed it as one of those not-in-tip-area warnings. Sorry about
that, I'll try to pay more attention in the future.
> I see that the -mm tree has a fix for this, but I'm rather unhappy
> that the -tip tree build checking has deteriorated so much, and clang
> builds will now have a pointless build error that will cause issues
> for bisect.
Ah, you say build error because you have CONFIG_WERROR=y.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists