Re: [PATCH rdma-next v2 03/14] RDMA/core: Support renaming a device when changing its net namespace

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unreachable feature and silent failure in netlink handler for RDMA namespace moves
--

--- Patch [3]: [PATCH rdma-next v2 03/14] RDMA/core: Support renaming a device when changing its net namespace ---
commit 4056da04c986796c81666352d7fa9e90d5591d4e
Author: Jiri Pirko <jiri@nvidia.com>

RDMA/core: Support renaming a device when changing its net namespace

This commit introduces support for renaming an RDMA device when moving
it to a new network namespace. It preserves the literal-name path for
user requests and keeps the fallback naming on the teardown path.

> diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
> index 32b6c4d68ca0a..77a7580801486 100644
> --- a/drivers/infiniband/core/nldev.c
> +++ b/drivers/infiniband/core/nldev.c
[ ... ]
> @@ -1195,7 +1195,7 @@ static int nldev_set_doit(struct sk_buff *skb, struct nlmsghdr *nlh,
>  		u32 ns_fd;
>  
>  		ns_fd = nla_get_u32(tb[RDMA_NLDEV_NET_NS_FD]);
> -		err = ib_device_set_netns_put(skb, device, ns_fd);
> +		err = ib_device_set_netns_put(skb, device, ns_fd, NULL);

[Severity: High]
Does hardcoding NULL here make the newly introduced naming feature
unreachable from user space?

If a user space application sends an RDMA_NLDEV_CMD_SET netlink message
containing both RDMA_NLDEV_ATTR_DEV_NAME and RDMA_NLDEV_NET_NS_FD,
nldev_set_doit() appears to hardcode NULL for the destination name instead
of extracting and passing the requested name to ib_device_set_netns_put().

Additionally, if the RDMA_NLDEV_ATTR_DEV_NAME attribute is processed
separately in nldev_set_doit():

    if (tb[RDMA_NLDEV_ATTR_DEV_NAME]) {
        ...
        err = ib_device_rename(device, name);
        goto done;
    }

is there a risk that passing both attributes will cause the namespace
move to be silently skipped entirely because the rename block
unconditionally jumps to the end of the function?

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