[PATCH v4 06/35] cleanup: Basic compatibility with context analysis
Peter Zijlstra
peterz at infradead.org
Thu Dec 11 09:55:16 UTC 2025
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?
More information about the Linux-security-module-archive
mailing list