Re: [PATCH rdma-next 08/13] RDMA/cgroup: Scope rdma cgroup device visibility to the net namespace

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Scoping RDMA cgroup device visibility to the reader's network namespace breaks host-level cgroup administration and monitoring.
- [Medium] Concurrent lockless read of `device->net` using `read_pnet()` without `READ_ONCE()` leads to a data race.
--

--- Patch [8]: [PATCH rdma-next 08/13] RDMA/cgroup: Scope rdma cgroup device visibility to the net namespace ---
commit 18e4bddcfb08bd42bef710d6d1b72824d15fa2c9
Author: Jiri Pirko <jiri@resnulli.us>

RDMA/cgroup: Scope rdma cgroup device visibility to the net namespace

Track each rdma cgroup device's net namespace and sharing mode, then filter
name lookups and cgroupfs enumeration to devices visible from the caller's
namespace. Keep the cached sharing mode synchronized across registration,
netns moves, and runtime mode changes.

> diff --git a/kernel/cgroup/rdma.c b/kernel/cgroup/rdma.c
> index 5e82a03b3270a..c8b4e3de76305 100644
> --- a/kernel/cgroup/rdma.c
> +++ b/kernel/cgroup/rdma.c
[ ... ]
> @@ -464,6 +465,13 @@ void rdmacg_unregister_device(struct rdmacg_device *device)
>  }
>  EXPORT_SYMBOL(rdmacg_unregister_device);
>  
> +/* netns_shared is toggled without rdmacg_mutex, hence READ_ONCE(). */
> +static bool rdmacg_device_visible(const struct rdmacg_device *device)
> +{
> +	return READ_ONCE(device->netns_shared) ||
> +	       net_eq(read_pnet(&device->net), current->nsproxy->net_ns);

[Severity: Medium]
Does this lockless read of device->net using read_pnet() cause a data race?

When another thread concurrently moves the RDMA device to a new network
namespace, it updates device->net:

drivers/infiniband/core/cgroup.c:ib_device_rdmacg_change_netns() {
	write_pnet(&device->cg_device.net, net);
}

While write_pnet() uses rcu_assign_pointer() to update the pointer concurrently,
read_pnet() here expands to a plain pointer access without READ_ONCE(). Since
rdmacg_mutex is not held during the write, could this plain read race with the
assignment and cause undefined behavior?

[Severity: High]
Does tying RDMA cgroup device visibility to the reader's network namespace
break host-level cgroup administration and monitoring?

If a device is moved to a non-init network namespace (exclusive mode), host
administrators and orchestration tools (like systemd or Kubernetes running in
init_net) will completely lose visibility and control over its RDMA cgroup
resources. Attempting to write to rdma.max will result in -ENODEV, and reading
rdma.current will show an empty list for these devices.

Since cgroup state must reflect the cgroup's configuration independent of the
reading process's network namespace, does tying the UAPI to
current->nsproxy->net_ns violate VFS semantics where an open file descriptor's
behavior would dynamically change depending on which process calls write()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709095532.855647-1-jiri@resnulli.us?part=8