linux-kernel - Re: [PATCH v5 08/36] locking/rwlock, spinlock: Support Clang's context analysis

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 for Android: free password hash cracker in your pocket

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

Message-ID: <0088cc8c-b395-4659-854f-a6cc5df626ed@gmail.com>
Date: Fri, 19 Dec 2025 14:34:19 -0700
From: Bart Van Assche <bart.vanassche@...il.com>
To: Marco Elver <elver@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Boqun Feng <boqun.feng@...il.com>,
 Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
 "David S. Miller" <davem@...emloft.net>,
 Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
 Chris Li <sparse@...isli.org>, "Paul E. McKenney" <paulmck@...nel.org>,
 Alexander Potapenko <glider@...gle.com>, Arnd Bergmann <arnd@...db.de>,
 Christoph Hellwig <hch@....de>, Dmitry Vyukov <dvyukov@...gle.com>,
 Eric Dumazet <edumazet@...gle.com>, Frederic Weisbecker
 <frederic@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Herbert Xu <herbert@...dor.apana.org.au>, Ian Rogers <irogers@...gle.com>,
 Jann Horn <jannh@...gle.com>, Joel Fernandes <joelagnelf@...dia.com>,
 Johannes Berg <johannes.berg@...el.com>, Jonathan Corbet <corbet@....net>,
 Josh Triplett <josh@...htriplett.org>, Justin Stitt
 <justinstitt@...gle.com>, Kees Cook <kees@...nel.org>,
 Kentaro Takeda <takedakn@...data.co.jp>,
 Lukas Bulwahn <lukas.bulwahn@...il.com>, Mark Rutland
 <mark.rutland@....com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Miguel Ojeda <ojeda@...nel.org>, Nathan Chancellor <nathan@...nel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
 Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
 Steven Rostedt <rostedt@...dmis.org>,
 Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
 Thomas Gleixner <tglx@...utronix.de>, Thomas Graf <tgraf@...g.ch>,
 Uladzislau Rezki <urezki@...il.com>, Waiman Long <longman@...hat.com>,
 kasan-dev@...glegroups.com, linux-crypto@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linux-security-module@...r.kernel.org, linux-sparse@...r.kernel.org,
 linux-wireless@...r.kernel.org, llvm@...ts.linux.dev, rcu@...r.kernel.org
Subject: Re: [PATCH v5 08/36] locking/rwlock, spinlock: Support Clang's
 context analysis

On 12/19/25 2:02 PM, Marco Elver wrote:
> On Fri, 19 Dec 2025 at 21:26, Bart Van Assche <bvanassche@....org> wrote:
>> On 12/19/25 7:39 AM, Marco Elver wrote:
>>> - extern void do_raw_read_lock(rwlock_t *lock) __acquires(lock);
>>> + extern void do_raw_read_lock(rwlock_t *lock) __acquires_shared(lock);
>>
>> Given the "one change per patch" rule, shouldn't the annotation fixes
>> for rwlock operations be moved into a separate patch?
>>
>>> -typedef struct {
>>> +context_lock_struct(rwlock) {
>>>        arch_rwlock_t raw_lock;
>>>    #ifdef CONFIG_DEBUG_SPINLOCK
>>>        unsigned int magic, owner_cpu;
>>> @@ -31,7 +31,8 @@ typedef struct {
>>>    #ifdef CONFIG_DEBUG_LOCK_ALLOC
>>>        struct lockdep_map dep_map;
>>>    #endif
>>> -} rwlock_t;
>>> +};
>>> +typedef struct rwlock rwlock_t;
>>
>> This change introduces a new globally visible "struct rwlock". Although
>> I haven't found any existing "struct rwlock" definitions, maybe it's a
>> good idea to use a more unique name instead.
> 
> This doesn't actually introduce a new globally visible "struct
> rwlock", it's already the case before.
> An inlined struct definition in a typedef is available by its struct
> name, so this is not introducing a new name
> (https://godbolt.org/z/Y1jf66e1M).

Please take another look. The godbolt example follows the pattern
"typedef struct name { ... } name_t;". The "name" part is missing from
the rwlock_t definition. This is why I wrote that the above code
introduces a new global struct name.

Bart.