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

Leon Romanovsky <[email protected]>
Newsgroups org.kernel.vger.linux-rdma,org.kernel.vger.cgroups,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-s390,org.kernel.vger.netdev
Message-ID <20260722115323.GY110966@unreal>
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.

Thanks
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.