+20
−1
+3
−0
+5
−0
Loading
When removing a listener, for example with nvmf_subsystem_remove_listener RPC, we use the concept of a "listen trid" to determine which existing connections should be disconnected. This listen trid has the trtype, adrfam, traddr and trsvcid defined, but *not* the subnqn. We use the subsystem pointer itself to match the subsystem. nvmf_stop_listen_disconnect_qpairs gets the listen trid for each qpair, compares it to the trid passed by the RPC, and if it matches, then it compares the subsystem pointers and will disconnect the qpair if it matches. The problem is that the spdk_nvmf_qpair_get_listen_trid path does not initialize the subnqn to an empty string, and in this case the caller does not initialize it either. So sometimes the subnqn on the stack used to get the qpair's listen trid ends up with some garbage as the subnqn string, which causes the transport_id_compare to fail, and then the qpair won't get disconnected even if the other trid fields and subsystem pointers match. For the failover.sh test, this means that the qpair doesn't get disconnected, so we never go down the reset path on the initiator side and don't see the "Resetting" strings expected in the log. This similarly impacts the host/timeout.sh test, which is also fixed by this patch. There were multiple failing signatures, all related to remove_listener not working correctly due to this bug. While the get_listen_trid path is the one that caused these bugs, the get_local_trid and get_peer_trid paths have similar problems, so they are similarly fixed in this patch. Fixes issue #2862. Fixes issue #2595. Fixes issue #2865. Fixes issue #2864. Signed-off-by:Jim Harris <james.r.harris@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/17788 (master) (cherry picked from commit baf250e5) Change-Id: I36eb519cd1f434d50eebf724ecd6dbc2528288c3 Signed-off-by:
Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/17828 Tested-by:
SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by:
Jim Harris <james.r.harris@intel.com> Reviewed-by:
Konrad Sztyber <konrad.sztyber@intel.com>