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: <CANpmjNPm5861mmHYMHoC9ErRfbLxmTy=MYwfsGC-YTpgP+z-Bw@mail.gmail.com>
Date: Thu, 15 Jan 2026 18:58:32 +0100
From: Marco Elver <elver@...gle.com>
To: Bart Van Assche <bvanassche@....org>
Cc: Peter Zijlstra <peterz@...radead.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, 
	Steven Rostedt <rostedt@...dmis.org>, Kees Cook <kees@...nel.org>
Subject: Re: [PATCH tip/locking/core] compiler-context-analysis: Support
 immediate acquisition after initialization

On Thu, 15 Jan 2026 at 18:22, Bart Van Assche <bvanassche@....org> wrote:
> 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

An analysis that detects as many bugs as possible is useless if nobody
wants to use it.

> 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.

It's the fundamental mismatch between our philosophies here:
completeness vs. soundness, where I'm advocating for the former
(compile most code with few changes) and you for the latter (detect
all bugs), where one or the other approach trades false negatives
against false positives respectively. Our experience with kernel bug
detection and analysis tools (KASAN, KCSAN, KMSAN, UBSAN, syzkaller,
syzbot) has shown time and time again that false positives or an undue
amount of churn (in the form of awkward annotations) on developers is
not acceptable -- I tried hard to improve ergonomics and avoid false
positives of the current context analysis infra -- and the necessary
trade-off are all too often more false negatives, yet at the benefit
of resulting greater coverage.

For the patch in question here, I took Steve's comment [1] to heart:

> If tooling can't handle a simple pattern of initializing a lock than
> taking it, that's a hard show stopper of adding that tooling.

[1] https://lore.kernel.org/all/20260109080715.0a390f6b@gandalf.local.home/

A corollary of this would be "If tooling can't handle a simple pattern
of initializing a lock and guarded members, that's a hard show
stopper". So we need to support both: initializing guarded members,
and being able to take the lock after initialization in the same
scope.

And to give you a bit of compromise: As with other tooling, the more
pragmatic approach is to claw back soundness once coverage and users
have reached critical mass (months or years.. hard to say).

We have to walk before we run.

Thanks,
-- Marco