[RFC PATCH] nvme of: don't flush scan work inside reset context

[sagi@grimberg.me (Sagi Grimberg)]

>>> transports are
>>> several of the flush cases require an io to complete to finish 
>>> flushing -
>>> not just scan_work.?? nvme_mpath_stop() syncs with ctrl->ana_work, 
>>> which may
>>> be waiting for an ana log to complete.? fw_act_queues() may be in the 
>>> midst
>>> of polling the CSTS bit register or doing a fw_slot log read, or a
>>> stop_ctrl() routine for the transport may be in the middle of a 
>>> start_ctrl
>>> call.
>> These commands won't be retried since REQ_FAILFAST_DRIVER is set for any
>> request allocated via nvme_alloc_request().
>>
>> So the above flush cases you mentioned should be easier to handle than 
>> IO from
>> scan context. However, looks the patch we discussed before by moving
>> nvme_stop_ctrl() after nvme_rdma_shutdown_ctrl() is still needed for
>> avoiding hang on flush in these commands.
> 
> Agree - nvme_stop_ctrl() has to move so the transport routines that 
> stop/return the io can run.? Leaving it in the same place with an 
> argument won't be enough.

nvme_stop_ctrl() cannot move to after queue termination, it has to
barrier before moving forward. The things that must flush before
are async_event_work that does not go via the normal request path
that is quiesced and ->stop_ctrl() at least for the rdma case make
sure that no error recovery is concurrent with the reset/delete flow.

Perhaps we can move scan_work flush into nvme_remove_namespaces()
instead? I guess it makes sense that when we remove namespaces we don't
want a scan to run concurrently?