[PATCH v5 08/36] locking/rwlock, spinlock: Support Clang's context analysis
Bart Van Assche
bart.vanassche at gmail.com
Fri Dec 19 21:34:19 UTC 2025
On 12/19/25 2:02 PM, Marco Elver wrote:
> On Fri, 19 Dec 2025 at 21:26, Bart Van Assche <bvanassche at acm.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.
More information about the Linux-security-module-archive
mailing list