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: <7ad85953-7cc8-4925-bc08-6e97bdf8d0b6@kernel.org>
Date: Thu, 9 Oct 2025 22:08:04 +0900
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

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 :)


Yours sincerely,
Vincent Mailhol