+17
−10
Loading
After sending the Identify command, completion was polled in a loop. If the completion was lost or delayed, the admin timeout was not respected and control returned only after spdk_nvme_qpair_process_completions failed. This depends on TCP configuration and can take ~60s by default. Since the controller mutex is held during this flow, it not only blocks the execution thread but also other threads waiting for the lock. Fix by using nvme_wait_for_completion_robust_lock_timeout, which tracks the timeout. Its usage slightly deviates from the documented contract, but the command completion callback nvme_ctrlr_identify_active_ns_async_done was updated to behave similarly to nvme_completion_poll_cb. Change-Id: I0aac3ffa96c7a161e6fd5e51540a251e13b6329f Signed-off-by:Jacek Kalwas <jacek.kalwas@nutanix.com> Reviewed-on: https://review.spdk.io/c/spdk/spdk/+/26489 Reviewed-by:
Tomasz Zawadzki <tomasz@tzawadzki.com> Reviewed-by:
Jim Harris <jim.harris@nvidia.com> Tested-by:
SPDK Automated Test System <spdkbot@gmail.com> Community-CI: Mellanox Build Bot Reviewed-by:
Ben Walker <ben@nvidia.com>