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

[Sagi Grimberg]

>>>>> 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...
>>>>
>>>> To me the right answer would be to reject user commands on the admin
>>>> or I/O queue for the not live controller as the callers need to handle
>>>> it.  That seems to make more sense to me than a special admin queue
>>>> exception.
>>>
>>> So you say that we should never return BLK_STS_RESOURCE but rather fail
>>> all requests? regardless for multipath or not?
>>
>> How about we keep the exception for now. As I mentioned earlier, I 
>> have an ioctl retry patch coming for nvme-cli and if we agree with 
>> what it does then we can put in the reject and remove the exception.
> 
> I honestly don't think we should fail user I/O commands, there is no
> for us reason to do that.
> I also don't think we should fail user admin commands either, at least
> not in nvmf_check_ready.

Guys, we need to resolve this one, this is needed to prevent freeze
during reset from hanging.

As I said, any I/O that will use the ns->queue shouldn't be denied here
because it takes the q_usage_counter and will prevent a freeze (this is
true for both fs or user I/O commands).

I still think we should allow the admin ones as well and deny them
somewhere else if we want to, but I'm fine with keeping this exception
now because no one is expected to freeze the admin queue.

Let me know what you think. I want it to go into an rc soon.