Re: [PATCH rdma-next v3 00/14] RDMA: Make device names unique per net namespace

Wed, Jul 22, 2026 at 01:53:23PM +0200, [email protected] wrote:
>On Wed, Jul 22, 2026 at 01:19:00PM +0200, Jiri Pirko wrote:
>> Thu, Jul 16, 2026 at 03:23:01PM +0200, [email protected] wrote:
>> >From: Jiri Pirko <[email protected]>
>> >
>> >RDMA device names are unique system-wide today:
>> >__ib_device_get_by_name() checks a requested name against every
>> >registered device regardless of the network namespace it lives in.
>> >A device in one network namespace therefore cannot use a name already
>> >taken in another, even in exclusive netns mode (netns_mode=0) where
>> >the two are otherwise isolated. Net devices have no such restriction -
>> >their names only need to be unique within a network namespace.
>> >
>> >This series makes RDMA device names unique per network namespace,
>> >matching net device semantics, and adapts the users that assumed
>> >system-wide unique names.
>> >
>> >Scoping reuses the existing rdma_dev_access_netns() predicate, so
>> >behavior only changes in exclusive mode:
>> >  - shared mode (default): names stay unique system-wide, no change;
>> >  - exclusive mode: names only need to be unique within a namespace;
>> >  - CONFIG_NET_NS=n: everything is init_net, names stay system-wide
>> >    unique.
>> >
>> >There are two users that cannot be made per-namespace and are
>> >documented as known limitations instead of changed:
>> >  - the rdma_cm configfs tree: configfs has no network namespace
>> >    support, so it cannot represent two same-named devices;
>> >  - SELinux ibendport labelling: endports are labelled by (device
>> >    name, port) from a global policy; distinguishing same-named
>> >    devices would need net namespace support in the SELinux policy
>> >    language and tooling.
>> >
>> >Tested with the new rxe_netns_names kselftest added in the last patch.
>> 
>> This looks like good to go. All Sashiko findings are false positive or
>> unrelated. Care to merge? Thanks!
>
>We usually take extra time before merging complex changes touching
>core or UAPI code.

Sure, I just wanted to let you know the ball is on your side. Take your
time of course :)

Thanks!