On Fri, 19 Dec 2025 at 22:34, Bart Van Assche <[email protected]> wrote: > > On 12/19/25 2:02 PM, Marco Elver wrote: > > On Fri, 19 Dec 2025 at 21:26, Bart Van Assche <[email protected]> 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.
You're right. My point only applies to "typedef struct spinlock ..."
