[PATCH v3 2/9] nvme-fabrics: allow to queue requests for live queues

[Sagi Grimberg]

>> I still dislike any random ioctls coming in while we're still initializing
>> the controller.
> 
> Agreed.
> 
>>    Looking at the flow - I wouldn't want them to be allowed
>> until after nvme_init_identify() is complete. Especially if the ioctls are
>> doing subsystem or controller dumping or using commands that should be
>> capped by values set by nvme_queue_limits().   But, if we're going to
>> allow nvme_init_identify the admin_q needs to be unquiesced.
>>
>> So I'm still voting for the admin queue exception.
> 
> And I really don't like the admin queue special case.  What is the
> advantage of letting user space passthrough I/O commands in at this
> point in time?

I checked again, and regarding the comment:

"I'm still rather bothered with the admin queue exception.  And given that
the q_usage_counter problem should only really be an issue for file system
requests, as passthrough requests do not automatically get retried why
can't we just reject all user command to be symetric and straight forward?
The callers in userspace need to be able to cope with retryable errors
anyway."

blk_mq_alloc_request calls blk_queue_enter, which means that if we don't
let them in, controller reset can hang, just like in normal fs I/O.

So we either keep this exception for admin commands, or we also let
them through as it seems to be safe with the current code (from the
reset forward-progress perspective).

I vote to remove this exception altogether...