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

[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();
    ...
}

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.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825095422.3166067-1-ruanjinjie@huawei.com?part=1