On Tue, Dec 16, 2025 at 02:23:19PM +0100, Marco Elver wrote: > > Also, why do we need this second variable with cleanup; can't the > > existing __scoped_seqlock_cleanup() get the __releases_shared() > > attribute? > > The existing __scoped_seqlock_cleanup() receives &_s (struct ss_tmp *), > and we can't refer to the _seqlock from __scoped_seqlock_cleanup(). Even > if I create a member seqlock_t* ss_tmp::seqlock and initialize it with > _seqlock, the compiler can't track that the member would be an alias of > _seqlock. The function __scoped_seqlock_next() does receive _seqlock to > effectively release it executes for every loop, so there'd be a "lock > imbalance" in the compiler's eyes. > > So having the direct alias (even if we cast it to make it work in the > single-statement multi-definition, the compiler doesn't care) is > required for it to work.
Right -- it just clicked while I was walking outside. Without actual inlining it cannot see through the constructor and track the variable :/ OK, let me stare at this more.
