Re: [PATCH rdma-next v2 14/14] RDMA/selftests: Add rxe_netns_names test

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Asynchronous RXE device deletion causes race conditions and test failures.
- [Medium] Asynchronous network namespace deletion causes test teardown to permanently leak the exclusive netns mode.
--

--- Patch [14]: [PATCH rdma-next v2 14/14] RDMA/selftests: Add rxe_netns_names test ---
commit dcc30384e696a4047f319e3b7139b30b3ddc09f4
Author: Jiri Pirko <jiri@resnulli.us>

RDMA/selftests: Add rxe_netns_names test

Add a kselftest script that exercises per-netns RDMA device naming
with RXE. Cover duplicate names across namespaces, move conflict
handling, move-with-rename, and same-namespace rename requests.

> diff --git a/tools/testing/selftests/rdma/rxe_netns_names.sh b/tools/testing/selftests/rdma/rxe_netns_names.sh
> new file mode 100755
> --- /dev/null
> +++ b/tools/testing/selftests/rdma/rxe_netns_names.sh

[ ... ]

> +cleanup_devs()
> +{
> +	ip link del "$DUMMY_A" 2>/dev/null
> +	ip link del "$DUMMY_B" 2>/dev/null
> +}

[Severity: Medium]
Will this cause race conditions between test iterations?

The ip link del command returns as soon as the netdev reference is dropped,
but the rdma_rxe driver handles the NETDEV_UNREGISTER event by scheduling an
asynchronous unregistration of the RDMA device via
ib_unregister_device_queued().

Could the next test iteration fail with -EEXIST when attempting to create or
rename a device to the exact same name (like $RXE_SAME) if the asynchronous
device_del() from the previous test hasn't finished?

[ ... ]

> +cleanup()
> +{
> +	cleanup_devs
> +
> +	ip netns del "$NS1" 2>/dev/null
> +	ip netns del "$NS2" 2>/dev/null
> +
> +	if [ "$MODE_CHANGED" -eq 1 ]; then
> +		rdma system set netns "$OLD_MODE" 2>/dev/null
> +	fi

[Severity: Medium]
Does this cleanup sequence permanently leak the exclusive netns mode?

The ip netns del command initiates asynchronous teardown by queuing
net_cleanup_work. If rdma system set netns "$OLD_MODE" is executed
immediately afterwards while the namespaces are still in the process of being
destroyed, the kernel might reject the mode change with -EBUSY.

Since the script redirects errors to /dev/null, it seems the system's RDMA
subsystem could permanently be left in exclusive mode instead of being
restored to its original shared mode.

> +
> +	for m in "${MODS[@]}"; do
> +		modprobe -r "$m" 2>/dev/null
> +	done
> +}

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