[PATCHv2] nvme: ensure disabling pairs with unquiesce

[Keith Busch]

On Wed, Jul 12, 2023 at 06:13:27PM +0200, Christoph Hellwig wrote:
> On Wed, Jul 12, 2023 at 08:40:04AM -0700, Keith Busch wrote:
> > +disable:
> > +	if (!nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_RESETTING))
> > +		return BLK_EH_DONE;
> > +
> > +	nvme_dev_disable(dev, false);
> > +	if (nvme_try_sched_reset(&dev->ctrl))
> > +		nvme_unquiesce_io_queues(&dev->ctrl);
> > +	return BLK_EH_DONE;
> 
> Just curious, do you remember why we do an explicitnvme_dev_disable
> here instead of relying on the one at the beginning of
> nvme_dev_disable?  This isn't new, and the patch should not be blocked
> on it, but it looks very odd to me an we'll need to either document
> it or kill it eventually..

You mean why not rely on the disable in nvme_reset_work()? Because we're
in our timeout callback and can reclaim everything inline with the
notification. If we defer the disabling to the reset_work, the timeout
workqueue will keep running for potentially 1000's of outstanding IOs
for not particular reason. Not that that's a horrible thing, but it's
just inefficient. This was one of the nice benefits of switching the
timeout handling from a timer to workqueue.