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

[Jiri Pirko <jiri@resnulli.us>]

Fri, Jul 10, 2026 at 11:56:29AM +0200, sashiko-bot@kernel.org wrote:
>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()?

This report made me think a bit more about the current approach.
A cgroup may contain processes using devices from multiple network
namespaces, so caller-relative filtering can hide part of its state
from host administrators and make the same open file behave differently
depending on the calling task. That does not look and feel correct.

Instead, to handle device names that are duplicated across network
namespaces, v2 will use the system-wide RDMA device index for
disambiguation. The existing name-only format will remain unchanged
for unique names. For duplicate names, reads will include an `index=N`
selector and writes will require it; ambiguous name-only writes will
fail with `-ENOTUNIQ`.