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

[Jiri Pirko <jiri@resnulli.us>]

Wed, Jul 15, 2026 at 04:30:45PM +0200, sashiko-bot@kernel.org wrote:
>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?

will be fixed in v3

>
>[ ... ]
>
>> +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.

will be fixed in v3

>
>> +
>> +	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