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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260119091045.GA8181@lst.de>
Date: Mon, 19 Jan 2026 10:10:45 +0100
From: Christoph Hellwig <hch@....de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Christoph Hellwig <hch@....de>, Marco Elver <elver@...gle.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>, Will Deacon <will@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>, Waiman Long <longman@...hat.com>,
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
	Bart Van Assche <bvanassche@....org>
Subject: Re: [PATCH tip/locking/core] compiler-context-analysis: Support
 immediate acquisition after initialization

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.