linux-kernel - Re: [PATCH] locking/mutex:add MUTEX_CHCEK_INIT to detect uninitialized mutex lock

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: <20250924065823.GS4067720@noisy.programming.kicks-ass.net>
Date: Wed, 24 Sep 2025 08:58:23 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Waiman Long <llong@...hat.com>
Cc: buckzhang1212@...h.net, Ingo Molnar <mingo@...hat.com>,
	Will Deacon <will@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] locking/mutex:add MUTEX_CHCEK_INIT to detect
 uninitialized mutex lock

On Tue, Sep 23, 2025 at 11:10:22PM -0400, Waiman Long wrote:
> On 9/23/25 10:25 PM, buckzhang1212@...h.net wrote:

> A mutex must be properly initialized before it can be used. The kernel panic
> you listed above is expected and the panic itself indicates that the code is
> wrong.

> > @@ -269,6 +279,7 @@ static void __sched __mutex_lock_slowpath(struct mutex *lock);
> >   void __sched mutex_lock(struct mutex *lock)
> >   {
> >   	might_sleep();
> > +	MUTEX_CHCEK_INIT(lock);
> >   	if (!__mutex_trylock_fast(lock))
> >   		__mutex_lock_slowpath(lock);
> 
> This check has provided no additional value and it slows down the locking
> fast path.
> 
> NACK

Agreed. Additionally we have CONFIG_DEBUG_MUTEXES. If you feel there is
a check missing there -- you could argue that debug_mutex_lock_common()
should have something like:

  DEBUG_LOCK_WARN_ON(lock->magic != lock);

feel free to send a patch for that.

But don't go sprinkle debug code in !debug builds.