[PATCH] nvme-pci: fix race between pci reset and nvme probe

[Ming Lei]

On Thu, Aug 04, 2022 at 03:55:14PM -0600, Keith Busch wrote:
> On Mon, Aug 01, 2022 at 08:57:53PM +0800, Ming Lei wrote:
> > After nvme_probe() returns, device lock is released, and PCI reset
> > handler may come, meantime reset work is just scheduled and should
> > be in-progress.
> > 
> > When nvme_reset_prepare() is run, all NSs may not be allocated yet
> > and each NS's request queue won't be frozen by nvme_dev_disable().
> > 
> > But when nvme_reset_done() is called for resetting controller, all
> > NSs may have been scanned successfully, and nvme_wait_freeze() is
> > called on un-frozen request queues, then wait forever.
> > 
> > Fix the issue by holding device lock for resetting from nvme probe.
> 
> Beyond the issues with locking the pci device, I think the problem you're
> describing is generic to any rescan that alters the namespace inventory, so we
> can't resolve it only on probe.

Yeah, just it is easier to trigger during the 1st scan when no any NS
exits.

> 
> Is it enough to track the frozen status within the namespace flags? Something
> like the following:

I guess the patch could avoid the issue.

Another way might be to remove nvme_wait_freeze() from nvme_reset_work(). No
see it is necessary:

- nvme_dev_add():

if (!dev->ctrl.tagset) {
	...
} else {
	blk_mq_update_nr_hw_queues(&dev->tagset, dev->online_queues - 1);
	...
} 

If there isn't tagset, there can't be IO; and if nr_hw_queues is to be
changed really, blk_mq_update_nr_hw_queues() will freeze queue, otherwise
it isn't necessary to nvme_wait_freeze() before calling
blk_mq_update_nr_hw_queues.



Thanks,
Ming