blktests does not update nvme_adrfam when using NVMET_TRTYPES #217
Description
I am not able to run the tests suite using TCP or RDMA transport type with FC together. TCP/RDMA alone work fine, FC alone works fine, but as soon it is combined there is a problem:
$ NVMET_TRTYPES="fc tcp" NVMET_BLKDEV_TYPES="files" ./check -o /tmp/blktests nvme/006
nvme/006 (tr=fc bd=files) (create an NVMeOF target) [passed]
runtime 0.345s ... 0.344s
nvme/006 (tr=tcp bd=files) (create an NVMeOF target)
nvme/006 (tr=tcp bd=files) (create an NVMeOF target) [failed]
runtime 0.270s ... 0.239sort: 0
--- tests/nvme/006.out 2023-08-30 08:39:08.425076281 +0000
+++ /tmp/blktests/nodev_tr_tcp_bd_files/nvme/006.out.bad 2025-11-26 12:23:51.133615735 +0000
@@ -1,2 +1,3 @@
Running nvme/006
+ln: failed to create symbolic link '/sys/kernel/config/nvmet/ports/0/subsystems/blktests-subsystem-1': Invalid argument
Test completeI was not able to trace it down where the problem originates yet. As far I can tell is that TCP run is not able to setup a new target because there is something left from the FC run.
One theory I had is that there the FC target needs some time to disapear (remember when adding the FC controller, udev fires and systemd does a nvme connect-all). I added sleeps and try loops in the shutdown path and nothing really helped. So I am not totally convinced this a race window. But I don't understand why the ln steps files, when I added various while ! rm ...; do sleep 1; done for all the ports and subsystem. There should nothing prevent to ln the new subsystem.
(I've just reported this here so it doesn't get lost or someone has a great idea how to debug this)