BLK_MQ_F_BLOCKING is set for nvme-tcp, and the blocking may be done inside
nvme_ns_head_submit_bio(), is that one problem?
The point of BLK_MQ_F_BLOCKING is that ->queue_rq can block, and
because of that it is not called from the submitting context but in
a work queue. nvme-tcp also sets QUEUE_FLAG_NOWAIT, just like all blk-mq
drivers.
BLK_MQ_F_BLOCKING can be called from submitting context, see
blk_mq_try_issue_directly().
The all drivers setting it have a problem, as the blk-mq core sets
BLK_MQ_F_BLOCKING for all of them. The right fix would be to not make
it block for REQ_NOWAIT I/O..
Hey Christoph and Ming,
I think that we can remove BLK_MQ_F_BLOCKING setting from nvme-tcp,
the reason that it was set it because lock_sock taken in sendpage is
taking the sk_lock mutex, however given that nvme_tcp_try_send is
protected with the queue send_mutex (which is taken with a
mutex_trylock) we can probably convert it to sendpage_locked...
Let me run it through some tests and get back to you...
