Re: [PATCH] locking/mutex: add MUTEX_WARN_ON to warn invalid mutex
From: Waiman Long
Date: Sun Sep 28 2025 - 11:55:28 EST
On 9/27/25 4:00 AM, buckzhang1212@xxxxxxxx wrote:
From: "buck.zhang" <buckzhang1212@xxxxxxxx>
Here is a kernel exception about mutex and I can recreate it stably.
First we define a struct contains a mutex.
Then allocate this struct by kmalloc without calling mutex_init.
Finally when multiple tasks call mutex_lock together,kernel will panic.
This lock is used normally when only one task is using at a time.
the exception reason is that lock->wait_list is an invalid kernel list.
I want to add more warnings when enable CONFIG_DEBUG_MUTEXES
kernel crash log:
Unable to handle kernel NULL pointer dereference at virtual address 0000000
pc: __mutex_add_waiter+0x68/0x160
lr: __mutex_add_waiter+0x128/0x160
sp: ffffffc0866f3ac0
x29: ffffffc0866f3ad0 x28: ffffff8095148000 x27: 0000000000000000
.............
x2: ffffffc0866f3b18 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
__mutex_add_waiter+0x68/0x160
__mutex_lock+0x48c/0x119c
__mutex_lock_slowpath+0x1c/0x2c
mutex_lock+0x48/0x144
Test case:
struct chip_mutex {
struct mutex tmutex;
};
static void work_handler1(struct chip_mutex *cmutex)
{
mutex_lock(&(cmutex->tmutex));
}
static void work_handler2(struct chip_mutex *cmutex)
{
mutex_lock(&(cmutex->tmutex));
}
static void chip_tmutex(void)
{
struct chip_mutex *cmutex;
cmutex = kzalloc(sizeof(struct chip_mutex),GFP_KERNEL);
work_handler1(cmutex);
------
work_handler2(cmutex);
}
Signed-off-by: buck.zhang <buckzhang1212@xxxxxxxx>
---
kernel/locking/mutex.c | 2 ++
kernel/locking/mutex.h | 11 +++++++++++
2 files changed, 13 insertions(+)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index de7d6702c..318d98f2f 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -574,6 +574,8 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
might_sleep();
+ /* In case the mutex is uninitiated, add more warning */
+ MUTEX_WARN_ON(mutex_waitlist_invalid(&lock->wait_list));
MUTEX_WARN_ON(lock->magic != lock);
By enabling CONFIG_DEBUG_MUTEXES, the lock->magic check should have uncovered the case of mutex_lock() call without mutex initialization. The extra wait_list check is likely not necessary.
Cheers,
Longman