Re: [PATCH tip/locking/core] compiler-context-analysis: Support immediate acquisition after initialization

[Christoph Hellwig <hch@lst.de>]

On Fri, Jan 16, 2026 at 04:47:54PM +0100, Peter Zijlstra wrote:
> So the base problem here is something like:
> 
> struct obj {
> 	spinlock_t	lock;
> 	int		state __guarded_by(lock);
> };
> 
> struct obj *create_obj(void)
> {
> 	struct obj *obj = kzmalloc(sizeof(*obj), GFP_KERNEL);
> 	if (!obj)
> 		return NULL;
> 
> 	spin_lock_init(&obj->lock);
> 	obj->state = INIT_STATE; // error: ->state demands ->lock is held
> }
> 
> So if you want/can take spin_lock() directly after spin_lock_init(),
> then yes, you can write:

Which really is the normal case.

> However, if code is structured such that you need to init fields before
> taking the lock, you need a 'fake' lock acquire to wrap the
> initialization -- which is safe because there is no concurrency yet and
> all that, furthermore, by holding the fake lock you also ensure you
> cannot in fact take the lock and create undue concurrency before
> initialization is complete.

Well.  That assumes you have fields, or probably pointed to data
structures, where use under the lock is fine, but initializing them is
not.  Which sounds really weird.  And if you do that, splitting out a
separate function like in the patch that trigger all this sounds
perfectly fine.  It's the simple case you mentiond above that is fairly
common and really needs to work.  Especially as the allocate and init
helpers for them are often pretty trivial.

That being said, even outside this pattern the concept of allowing
initialization to touch fields before the containing structure is
published and can be found by other threads is a common and useful
one.  Having that supported natively in context tracking would probably
be useful if not required sooner or later.