[PATCH 07/13] libmultipath: Add delayed removal support

[John Garry]

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