[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAADnVQK_Dt7Ag9nLQm2LDFoiB_ymorC017YXJ9ZC06VizEHt2A@mail.gmail.com>
Date: Tue, 23 Sep 2025 12:38:26 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Vincent Mailhol <mailhol@...nel.org>
Cc: Vlastimil Babka <vbabka@...e.cz>, Shakeel Butt <shakeel.butt@...ux.dev>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Alexei Starovoitov <ast@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] locking/local_lock: fix shadowing in __local_lock_acquire()
On Tue, Sep 23, 2025 at 7:02 AM Vincent Mailhol <mailhol@...nel.org> wrote:
>
> The __local_lock_acquire() macro uses a local variable named 'l'. This
> being a common name, there is a risk of shadowing other variables.
>
> For example, it is currently shadowing the parameter 'l' of the:
>
> class_##_name##_t class_##_name##_constructor(_type *l)
>
> function factory from linux/cleanup.h.
>
> Both sparse (with default options) and GCC (with W=2 option) warn
> about this shadowing.
>
> This is a bening warning, but because the issue appears in a header,
> it is spamming whoever is using it. So better to fix to remove some
> noise.
>
> Rename the variable from 'l' to '__lock' (with two underscore prefixes
> as suggested in the Linux kernel coding style [1]) in order to prevent
> the name collision.
lockdep has __lock as a local variable.
So the patch won't really fix the paranoid warning.
I think it's better to fix sparse to silence this warn.
Powered by blists - more mailing lists