On Thu, Nov 20, 2025 at 04:09:31PM +0100, Marco Elver wrote: > Introduce basic compatibility with cleanup.h infrastructure: introduce > DECLARE_LOCK_GUARD_*_ATTRS() helpers to add attributes to constructors > and destructors respectively. > > Note: Due to the scoped cleanup helpers used for lock guards wrapping > acquire and release around their own constructors/destructors that store > pointers to the passed locks in a separate struct, we currently cannot > accurately annotate *destructors* which lock was released. While it's > possible to annotate the constructor to say which lock was acquired, > that alone would result in false positives claiming the lock was not > released on function return. > > Instead, to avoid false positives, we can claim that the constructor > "assumes" that the taken lock is held via __assumes_ctx_guard(). > > This will ensure we can still benefit from the analysis where scoped > guards are used to protect access to guarded variables, while avoiding > false positives. The only downside are false negatives where we might > accidentally lock the same lock again: > > raw_spin_lock(&my_lock); > ... > guard(raw_spinlock)(&my_lock); // no warning > > Arguably, lockdep will immediately catch issues like this. > > While Clang's analysis supports scoped guards in C++ [1], there's no way > to apply this to C right now. Better support for Linux's scoped guard > design could be added in future if deemed critical.
Moo, so the alias analysis didn't help here?
