Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220303110755.24147-1-mailhol.vincent@wanadoo.fr> <CAKwvOd=Fyu6S=pK-tGeYgoJL3ntGRSC0EQ6si8Cdg9q2pn0a6A@mail.gmail.com>
In-Reply-To: <CAKwvOd=Fyu6S=pK-tGeYgoJL3ntGRSC0EQ6si8Cdg9q2pn0a6A@mail.gmail.com>
From:   Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Date:   Sat, 5 Mar 2022 12:57:50 +0900
Message-ID: <CAMZ6Rq+DmXexN62m8AxPrjT=Fi=3fEg_VVjOOm3YV+X22Td0PA@mail.gmail.com>
Subject: Re: [PATCH] x86/bug: __WARN_FLAGS: prevent shadowing by renaming
 local variable f to __flags
To:     Nick Desaulniers <ndesaulniers@google.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
        Alexey Dobriyan <adobriyan@gmail.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Tue. 5 Mar 2022 à 04:26, Nick Desaulniers <ndesaulniers@google.com> wrote:
> On Thu, Mar 3, 2022 at 3:08 AM Vincent Mailhol
> <mailhol.vincent@wanadoo.fr> wrote:
> > The macro __WARN_FLAGS() uses a local variable named "f". This being a
> > common name, there is a risk of shadowing other variables.
> >
> > For example:
> >
> > | In file included from ./include/linux/bug.h:5,
> > |                  from ./include/linux/cpumask.h:14,
> > |                  from ./arch/x86/include/asm/cpumask.h:5,
> > |                  from ./arch/x86/include/asm/msr.h:11,
> > |                  from ./arch/x86/include/asm/processor.h:22,
> > |                  from ./arch/x86/include/asm/timex.h:5,
> > |                  from ./include/linux/timex.h:65,
> > |                  from ./include/linux/time32.h:13,
> > |                  from ./include/linux/time.h:60,
> > |                  from ./include/linux/stat.h:19,
> > |                  from ./include/linux/module.h:13,
> > |                  from virt/lib/irqbypass.mod.c:1:
> > | ./include/linux/rcupdate.h: In function 'rcu_head_after_call_rcu':
> > | ./arch/x86/include/asm/bug.h:80:21: warning: declaration of 'f' shadows a parameter [-Wshadow]
> > |    80 |         __auto_type f = BUGFLAG_WARNING|(flags);                \
> > |       |                     ^
> > | ./include/asm-generic/bug.h:106:17: note: in expansion of macro '__WARN_FLAGS'
> > |   106 |                 __WARN_FLAGS(BUGFLAG_ONCE |                     \
> > |       |                 ^~~~~~~~~~~~
> > | ./include/linux/rcupdate.h:1007:9: note: in expansion of macro 'WARN_ON_ONCE'
> > |  1007 |         WARN_ON_ONCE(func != (rcu_callback_t)~0L);
> > |       |         ^~~~~~~~~~~~
> > | In file included from ./include/linux/rbtree.h:24,
> > |                  from ./include/linux/mm_types.h:11,
> > |                  from ./include/linux/buildid.h:5,
> > |                  from ./include/linux/module.h:14,
> > |                  from virt/lib/irqbypass.mod.c:1:
> > | ./include/linux/rcupdate.h:1001:62: note: shadowed declaration is here
> > |  1001 | rcu_head_after_call_rcu(struct rcu_head *rhp, rcu_callback_t f)
> > |       |                                               ~~~~~~~~~~~~~~~^
> >
> > This patch renames the variable from f to __flags (with two underscore
> > prefixes as suggested in the Linux kernel coding style [1]) in order
> > to prevent collisions.
> >
> > [1] Linux kernel coding style, section 12) Macros, Enums and RTL,
> > paragraph 5) namespace collisions when defining local variables in
> > macros resembling functions
> > https://www.kernel.org/doc/html/v4.10/process/coding-style.html#macros-enums-and-rtl

Indeed! Will update this in v2 (and will also fix the Fixes: tag as
pointed by Josh).

> Ah, thanks for the patch. I missed that coding style recommendation.
> Might want to link to a newer (or evergreen) version of the docs
> though:
> https://www.kernel.org/doc/html/latest/process/coding-style.html#macros-enums-and-rtl
> Not sure what happens when we start shadowing variables named __flags,
> but maybe we cross that bridge if/when we get there.

Ack.

> Thanks for the fix!
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>