On 10/04/2026 10:09, Nilay Shroff wrote:
It seems there may be a race here if we attempt to write to $ns before
the reconnect has completed in _delayed_nvme_reconnect_ctrl.
If the intention is simply to verify that the controller reconnect
occurs
within the delayed removal window and test pwrite,
Not exactly. I want to verify that if I write between the disconnect
and the reconnect, then we write succeeds.
Okay, got it — I think I misunderstood the intention earlier.
So the goal here is to verify that if a write is issued during the
delayed removal window is in progress (i.e., when there is temporarily
no active path), the write should be queued. Once the reconnect succeeds,
the queued write should then be unblocked and sent to the target.
Yeah, that's it. Otherwise, the write will be queued but then eventually
fail (for no reconnect).
If this understanding is correct, then this looks like a good test
to me.
thanks
About the module refcounting, as I mentioned earlier it's hard to test
this effectively. We could use lsmod to check refcount on nvme ko during
the delayed removal window and ensure that it was incremented. I'm not
sure if it is robust and whether the complexity is worth it.
Cheers,
John
