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.
