Re: [PATCH v4 07/35] lockdep: Annotate lockdep assertions for context analysis

On Thu, Dec 11, 2025 at 02:24:57PM +0100, Marco Elver wrote:

> > It is *NOT* (as the clang naming suggests) an assertion of holding the
> > lock (which is requires_ctx), but rather an annotation that forces the
> > ctx to be considered held.
> 
> Noted. I'll add some appropriate wording above the
> __assumes_ctx_guard() attribute, so this is not lost in the commit
> logs.

On IRC you stated:

<melver> peterz: 'assume' just forces the compiler to think something is
  held, whether or not it is then becomes the programmer's problem. we
  need it in 2 places at least: for the runtime assertions (to help
  patterns beyond the compiler's static reasoning abilities), and for
  initialization (so we can access guarded variables right after
  initialization; nobody should hold the lock yet)

I'm really not much a fan of that init hack either ;-)

Once we get the scope crap working sanely, I would much rather we move
to something like:

	scoped_guard (spinlock_init, &foo->lock) {
		// init foo fields
	}

or perhaps:

	guard(mutex_init)(&bar->lock);
	// init until end of current scope

Where this latter form is very similar to the current semantics where
mutex_init() will implicitly 'leak' the holding of the lock. But the
former gives more control where we need it.