Re: [PATCH v2 02/34] compiler-capability-analysis: Add infrastructure for Clang's capability analysis

Marco Elver
2025-03-04T16:06:11Z

On Tue, 4 Mar 2025 at 16:29, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Mar 04, 2025 at 10:21:01AM +0100, Marco Elver wrote:
>
> > +# define __asserts_cap(var) __attribute__((assert_capability(var)))
> > +# define __asserts_shared_cap(var) __attribute__((assert_shared_capability(var)))
>
> > + static __always_inline void __assert_cap(const struct name *var) \
> > + __attribute__((overloadable)) __asserts_cap(var) { } \
> > + static __always_inline void __assert_shared_cap(const struct name *var) \
> > + __attribute__((overloadable)) __asserts_shared_cap(var) { } \
>
> Since this does not in fact check -- that's __must_hold(), I would
> suggest renaming these like s/assert/assume/.

Yeah, that's better.

FTR - the "asserts_capability" attribute was originally meant to be
used on runtime functions that check that a lock is held at runtime;
what Clang does underneath is simply adding the given capability/lock
to the held lockset, so no real checking is enforced. In this series
it's used for a lot more than just our lockdep_assert*() helpers, so
the "assert" naming is indeed confusing.

Thanks!