linux-kernel - Re: [PATCH v3] locking/local_lock: s/l/__l/ and s/tl/_

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMZ6RqLZOEzhtwUPwD=Zjx33yE3FajOXsHx0aNfkXc+ST9UrJA@mail.gmail.com>
Date: Wed, 26 Nov 2025 13:21:41 +0100
From: Vincent Mailhol <mailhol@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>, 
	Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>, 
	Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH v3] locking/local_lock: s/l/__l/ and s/tl/__tl/ to reduce
 risk of shadowing

Hi Sebastian,

On Thu. 9 Oct. 2025 at 15:08, Vincent Mailhol <mailhol@...nel.org> wrote:
> On 09/10/2025 at 21:43, Sebastian Andrzej Siewior wrote:
> > On 2025-10-09 21:39:07 [+0900], Vincent Mailhol wrote:
> >> Hi Sebastian,
> > Hi Vincent,
> >
> >> On 09/10/2025 at 19:39, Sebastian Andrzej Siewior wrote:
> >>
> >> (...)
> >>
> >>> @@ -223,12 +223,12 @@ typedef spinlock_t local_trylock_t;
> >>>  #define INIT_LOCAL_LOCK(lockname) __LOCAL_SPIN_LOCK_UNLOCKED((lockname))
> >>>  #define INIT_LOCAL_TRYLOCK(lockname) __LOCAL_SPIN_LOCK_UNLOCKED((lockname))
> >>>
> >>> -#define __local_lock_init(l)                                       \
> >>> +#define __local_lock_init(__l)                                     \
> >>>     do {                                                    \
> >>> -           local_spin_lock_init((l));                      \
> >>> +           local_spin_lock_init((__l));                    \
> >>>     } while (0)
> >>>
> >>> -#define __local_trylock_init(l)                    __local_lock_init(l)
> >>> +#define __local_trylock_init(__l)                  __local_lock_init(__l)
> >>>
> >>>  #define __local_lock(__lock)                                       \
> >>>     do {                                                    \
> >>
> >> The parameters of a function like macro can not shadow existing
> >> symbols because, when invoked, these parameters would be substituted
> >> during the macro expansion by the actual arguments. Only the local
> >> variables declared in the macro would survive after the preprocessor
> >> and thus only those may cause shadowing.
> >>
> >> So this last part of the patch is not needed.
> >
> > Right, but then we have the same __l variable in the whole file. Isn't
> > this worth something?
>
> What I really wanted to point out is that this is not needed in
> regards to the shadowing problem. So this part feels a bit out of
> scope of what the patch is trying to achieve.
>
> That said, if you as a maintainer think that it is better to add this
> for the global harmony of the file, then I am OK. I wouldn't do that
> in a file which I maintain, but the maintainer here is you, not me. It
> make sense that you do it your preferred way.
>
> In other words, if you like it this way, keep the patch as is :)

I just wanted to check if everything was OK with that patch. I am
asking because I did not find it in linux-next.


Yours sincerely,
Vincent Mailhol