On 12/4/2018 9:23 AM, Sagi Grimberg wrote:

quoted

quoted

quoted

quoted

Yes, I'm very much in favour of this, too.
We always have this IMO slightly weird notion of stopping the 
queue, set
some error flags in the driver, then _restarting_ the queue, just so
that the driver then sees the error flag and terminates the requests.
Which I always found quite counter-intuitive.

What about requests that come in after the iteration runs? how are 
those
terminated?

If we've reached a dead state, I think you'd want to start a queue 
freeze
before running the terminating iterator.

For the requests that come in after the iterator, the 
nvmf_check_ready() routine, which validates controller state, will 
catch and bounce them.

The point of this patch was to omit the check in queue_rq like Keith
did in patch #2.

well - I'm not sure that's possible. The fabrics will have different 
time constraints vs pci.

-- james