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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c708b1c5-1165-47e6-a93c-54b2928716b6@acm.org>
Date: Thu, 15 Jan 2026 09:22:49 -0800
From: Bart Van Assche <bvanassche@....org>
To: Marco Elver <elver@...gle.com>, Peter Zijlstra <peterz@...radead.org>,
 Ingo Molnar <mingo@...nel.org>
Cc: 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
Subject: Re: [PATCH tip/locking/core] compiler-context-analysis: Support
 immediate acquisition after initialization

On 1/14/26 4:51 PM, Marco Elver wrote:
> To do so *only* within the initialization scope, we can cast the lock
> pointer to any reentrant type for the init assume/assert. Introduce a
> generic reentrant context lock type `struct __ctx_lock_init` and add
> `__inits_ctx_lock()` that casts the lock pointer to this type before
> assuming/asserting it.
> 
> This ensures that the initial "held" state is reentrant, allowing
> patterns like:
> 
>    mutex_init(&lock);
>    ...
>    mutex_lock(&lock);
> 
> to compile without false positives, and avoids having to make all
> context lock types reentrant outside an initialization scope.
> 
> The caveat here is missing real double-lock bugs right after init scope.
> However, this is a classic trade-off of avoiding false positives against
> (unlikely) false negatives.

The goal of lock context analysis is to detect as many locking bugs at
compile time as possible. As mentioned above, with this patch applied, a
class of real bugs won't be detected: recursive locking in the context
of the initialization of the synchronization object. Hence, I think this
patch is a step in the wrong direction.

Even without this patch there is a class of locking bugs that is not
detected, namely unpaired synchronization object release calls in the
context of synchronization object initialization. An example for struct
mutex of this type of incorrect use of the mutex API that won't be
detected even without this patch:

	mutex_init(&mutex);
	...
	mutex_unlock(&mutex);

My preference is to remove __assume_ctx_lock() from mutex_init() and
similar macros in .h files and to add __assume_ctx_lock() explicitly in
the .c code that needs it. This will reduce significantly the chance
that the locking bug mentioned above is not detected at compile time.

Bart.