+7
−17
Loading
When an I/O qpair fails, poll_status needs to be released — just like for the admin qpair. Initial fix was introduced with 1c733603 and Related to #3207 but was not covering IO qpairs as there was no test catching the issue. However the same leak is possible for IOs as there is no other code to handle such negative case. Running UTs available here https://review.spdk.io/c/spdk/spdk/+/22350 with changes +DEFINE_STUB_V(nvme_poll_group_write_disconnect_qpair_fd, (struct spdk_nvme_poll_group *group)); - SPDK_CU_ASSERT_FATAL(nvme_qpair_init(qpair, 0, &ctrlr, 0, 1, true) == 0); + SPDK_CU_ASSERT_FATAL(nvme_qpair_init(qpair, 1, &ctrlr, 0, 1, true) == 0); allows to reproduce the issue for IO qpairs as well. While addressing this, also simplify the handling: regardless of the qpair type, nvme_ctrlr_disconnect_qpair can be used, since the mutex is recursive because of that removed the comment explaining the difference. Change-Id: Ic53704f6d3839b2b85d2b88d73955eb97a8a60ea Signed-off-by:Jacek Kalwas <jacek.kalwas@nutanix.com> Reviewed-on: https://review.spdk.io/c/spdk/spdk/+/26116 Tested-by:
SPDK Automated Test System <spdkbot@gmail.com> Reviewed-by:
Artur Paszkiewicz <artur.paszkiewicz@solidigm.com> Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Reviewed-by:
Konrad Sztyber <ksztyber@nvidia.com> Reviewed-by:
Jim Harris <jim.harris@nvidia.com> Reviewed-by:
Tomasz Zawadzki <tomasz@tzawadzki.com>