Re: [PATCH 01/11] user_namespace: Use acquire/release for nr_extents synchronization

[Jinjie Ruan <ruanjinjie@huawei.com>]

在 2026/8/26 17:54, sashiko-bot@kernel.org 写道:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The patch missed replacing `READ_ONCE()` and `smp_rmb()` with `smp_load_acquire()` in `copy_mnt_idmap()` within `fs/mnt_idmapping.c`.
> --
> 
> --- Patch [1]: [PATCH 01/11] user_namespace: Use acquire/release for nr_extents synchronization ---
> commit 1bcd6fdf3ca65990e2c5f3f0896df9c586813872
> Author: Jinjie Ruan <ruanjinjie@huawei.com>
> 
> user_namespace: Use acquire/release for nr_extents synchronization
> 
> This commit replaces smp_wmb() and smp_rmb() with smp_store_release() and
> smp_load_acquire() for nr_extents in user namespaces. This aims to improve
> performance on architectures with native acquire/release instructions.
> 
>> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
>> index 0bed462e9b2a2..576b667a88136 100644
>> --- a/kernel/user_namespace.c
>> +++ b/kernel/user_namespace.c
> 
> [ ... ]
> 
>> @@ -1098,8 +1100,8 @@ static ssize_t map_write(struct file *file, const char __user *buf,
>>  		map->forward = new_map.forward;
>>  		map->reverse = new_map.reverse;
>>  	}
>> -	smp_wmb();
>> -	map->nr_extents = new_map.nr_extents;
>> +	/* Pairs with smp_load_acquire() in map_id_range_{up,down}() and m_start(). */
>> +	smp_store_release(&map->nr_extents, new_map.nr_extents);
> 
> [Severity: Medium]
> Does this code miss updating copy_mnt_idmap() in fs/mnt_idmapping.c?
> 
> Since map_write() now uses smp_store_release() to update nr_extents, should
> the reader in copy_mnt_idmap() also be migrated to use smp_load_acquire()?
> 
> Currently it still uses the old barrier pattern and contains a stale comment:
> 
> fs/mnt_idmapping.c:copy_mnt_idmap() {
>     ...
> 	u32 nr_extents = READ_ONCE(map_from->nr_extents);
> 	/* Pairs with smp_wmb() when writing the idmapping. */
> 	smp_rmb();
>     ...
> }

Will fix it in v2.

> 
> While the release-store correctly pairs with the existing smp_rmb() under the
> Linux Kernel Memory Model, leaving the old barrier in place defeats the stated
> goal of avoiding the cost of full one-way barriers on architectures like arm64
> for this specific code path.
>