Re: [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