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

[Nilay Shroff]

On 4/8/26 9:58 PM, John Garry wrote:
> On 08/04/2026 16:41, Hannes Reinecke wrote:
>> On 4/8/26 13:28, John Garry wrote:
>>> On 02/03/2026 12:41, Nilay Shroff wrote:
>>>>> +
>>>>>   void mpath_add_sysfs_link(struct mpath_disk *mpath_disk)
>>>>>   {
>>>>>       struct mpath_head *mpath_head = mpath_disk->mpath_head;
>>>>> @@ -793,6 +868,8 @@ struct mpath_head *mpath_alloc_head(void)
>>>>>       mutex_init(&mpath_head->lock);
>>>>>       kref_init(&mpath_head->ref);
>>>>> +    mpath_head->delayed_removal_secs = 0;
>>>>> +
>>>>>       INIT_WORK(&mpath_head->requeue_work, mpath_requeue_work);
>>>>>       spin_lock_init(&mpath_head->requeue_lock);
>>>>>       bio_list_init(&mpath_head->requeue_list);
>>>>
>>>> I think we also need to initialize ->drv_module here.
>>>
>>> Hi Nilay,
>>>
>>> I am just coming back to this now. About NVMe multipath delayed disk removal, did you consider a blktests testcase to cover it? I might look at it if I have a chance (and it makes sense to do so).
>>>
>>
>> That look patently like the 'queue_if_no_path' feature from dm- multipath. Any chance of reconciling these two?
> 
> You mean a common blktests testcase, right?
> 
> For NVMe, that test would:
> a. try to remove NVMe ko when we have the delayed removal active
> b. ensure that we can queue for no path
> 
> I suppose that a common testcase could be possible (with dm mpath), but doesn't dm have its own testsuite?
> 
Yes, I'd add a blktest for 'queue_if_no_path' feature. But as we know we have
separate test suite for dm under blktests, I'd first target nvme testcase and
then later add another testcase for dm-multipath.
Thanks,
--Nilay