[PATCH] null_blk: initialize lock mutex before registering configfs subsystem

[PATCH] null_blk: initialize lock mutex before registering configfs subsystem

[Zizhi Wo]

From: Zizhi Wo <wozizhi@huawei.com>

In null_init(), mutex_init(&lock) currently happens after
configfs_register_subsystem(), which exposes the nullb subsystem to
userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach
null_find_dev_by_name() -> mutex_lock(&lock) before the mutex is
initialized, trigger warning:

[  123.137788] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[  123.137796] WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0, CPU#13: mkdir/1301
[  123.140090] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4
......
[  123.154926] Call Trace:
[  123.155172]  <TASK>
[  123.155419]  ? __pfx_mutex_lock+0x10/0x10
[  123.156181]  ? __pfx__raw_spin_lock+0x10/0x10
[  123.156571]  nullb_group_make_group+0x20/0x100 [null_blk]
[  123.157011]  configfs_mkdir+0x47b/0xc70
[  123.157337]  ? __pfx_configfs_mkdir+0x10/0x10
[  123.157719]  ? may_create_dentry+0x242/0x2e0
[  123.158061]  vfs_mkdir+0x2a9/0x6c0
[  123.158352]  filename_mkdirat+0x3dc/0x500
[  123.158710]  ? __pfx_filename_mkdirat+0x10/0x10
[  123.159070]  ? strncpy_from_user+0x3a/0x1d0
[  123.159413]  __x64_sys_mkdir+0x6b/0x90
[  123.159760]  do_syscall_64+0xea/0x600

Move mutex_init(&lock) before configfs_register_subsystem().

Fixes: 49c3b9266a71 ("block: null_blk: Improve device creation with configfs")
Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
---
 drivers/block/null_blk/main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c
index f8c0fd57e041..98616d290c5c 100644
--- a/drivers/block/null_blk/main.c
+++ b/drivers/block/null_blk/main.c
@@ -2161,13 +2161,12 @@ static int __init null_init(void)
 
 	config_group_init(&nullb_subsys.su_group);
 	mutex_init(&nullb_subsys.su_mutex);
+	mutex_init(&lock);
 
 	ret = configfs_register_subsystem(&nullb_subsys);
 	if (ret)
 		return ret;
 
-	mutex_init(&lock);
-
 	null_major = register_blkdev(0, "nullb");
 	if (null_major < 0) {
 		ret = null_major;
-- 
2.52.0

Re: [PATCH] null_blk: initialize lock mutex before registering configfs subsystem

[Bart Van Assche]

> diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c
> index f8c0fd57e041..98616d290c5c 100644
> --- a/drivers/block/null_blk/main.c
> +++ b/drivers/block/null_blk/main.c
> @@ -2161,13 +2161,12 @@ static int __init null_init(void)
>   
>   	config_group_init(&nullb_subsys.su_group);
>   	mutex_init(&nullb_subsys.su_mutex);
> +	mutex_init(&lock);
>   
>   	ret = configfs_register_subsystem(&nullb_subsys);
>   	if (ret)
>   		return ret;
>   
> -	mutex_init(&lock);
> -
>   	null_major = register_blkdev(0, "nullb");
>   	if (null_major < 0) {
>   		ret = null_major;

Why an explicit mutex_init() call instead of changing "static struct
mutex lock" into "static DEFINE_MUTEX(lock)"? Additionally, shouldn't
the "lock" name be made more descriptive since it has file scope?

Thanks,

Bart.

Re: [PATCH] null_blk: initialize lock mutex before registering configfs subsystem

[Zizhi Wo]

在 2026/7/4 21:25, Bart Van Assche 写道:
>> diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/ 
>> main.c
>> index f8c0fd57e041..98616d290c5c 100644
>> --- a/drivers/block/null_blk/main.c
>> +++ b/drivers/block/null_blk/main.c
>> @@ -2161,13 +2161,12 @@ static int __init null_init(void)
>>       config_group_init(&nullb_subsys.su_group);
>>       mutex_init(&nullb_subsys.su_mutex);
>> +    mutex_init(&lock);
>>       ret = configfs_register_subsystem(&nullb_subsys);
>>       if (ret)
>>           return ret;
>> -    mutex_init(&lock);
>> -
>>       null_major = register_blkdev(0, "nullb");
>>       if (null_major < 0) {
>>           ret = null_major;
> 
> Why an explicit mutex_init() call instead of changing "static struct
> mutex lock" into "static DEFINE_MUTEX(lock)"? Additionally, shouldn't
> the "lock" name be made more descriptive since it has file scope?
> 
> Thanks,
> 
> Bart.

Thanks for your suggestion, this is indeed more appropriate. I'll send
out a v2 shortly.

Thanks,
Zizhi Wo