[PATCH V3 4/6] nvme: paring quiesce/unquiesce

[Sagi Grimberg]

>>> There are lots of unbalanced usage in nvme, such as
>>>
>>> 1) nvme pci:
>>>
>>> - nvme_dev_disable() can be called more than one times before starting
>>> reset, so multiple nvme_stop_queues() vs. single nvme_start_queues().
>>>
>>> 2) Forcibly unquiesce queues in nvme_kill_queues() even though queues
>>> are never quiesced, and similar usage can be seen in tcp/fc/rdma too
>>>
>>> Once the quiesce and unquiesce are run from difference context, it becomes
>>> not easy to audit if the two is done in pair.
>>
>> Yes, but I'm not sure a magic flag is really the solution here.
>> I think we need to work on our state machine here so that this is less
>> of a mess.
> 
> Frankly speaking, I am not sure you can clean the whole mess in short time.
> 
> At least the approach of using the flag is clean and correct, and it can
> be reverted quite easily if you finally cleaned it.

I agree.

The assumption today is that quiesce/unquiesce are stateless in the
sense that they don't need to be paired.

At least for fabrics, the state-machine should be sufficient to
serialize the setup/teardown, but if we break the above assumption
we will need to remember if we are setting up after a reset (which
quiesced) or if we are setting up the controller for the first time
(or we artificially quiesce the queues in the first time as well).

As Ming pointed out, pci changes are more involved with non-trivial
scenarios.