CC'ing linux-block, this isn't an io_uring issue.
On 3/26/20 8:57 PM, Bijan Mottahedeh wrote:
> I'm seeing poll threads hang as I increase the number of threads in
> polled fio tests. I think this is because of polling on BLK_QC_T_NONE
> cookie, which will never succeed.
>
> A related problem however, is that the meaning of BLK_QC_T_NONE seems to
> be ambiguous.
>
> Specifically, the following cases return BLK_QC_T_NONE which I think
> would be problematic for polled io:
>
>
> generic_make_request()
> ...
> if (current->bio_list) {
> bio_list_add(¤t->bio_list[0], bio);
> goto out;
> }
>
> In this case the request is delayed but should get a cookie eventually.
> How does the caller know what the right action is in this case for a
> polled request? Polling would never succeed.
>
>
> __blk_mq_issue_directly()
> ...
> case BLK_STS_RESOURCE:
> case BLK_STS_DEV_RESOURCE:
> blk_mq_update_dispatch_busy(hctx, true);
> __blk_mq_requeue_request(rq);
> break;
>
> In this case, cookie is not updated and would keep its default
> BLK_QC_T_NONE value from blk_mq_make_request(). However, this request
> will eventually be reissued, so again, how would the caller poll for the
> completion of this request?
>
> blk_mq_try_issue_directly()
> ...
> ret = __blk_mq_try_issue_directly(hctx, rq, cookie, false, true);
> if (ret == BLK_STS_RESOURCE || ret == BLK_STS_DEV_RESOURCE)
> blk_mq_request_bypass_insert(rq, false, true);
>
> Am I missing something here?
>
> Incidentally, I don't see BLK_QC_T_EAGAIN used anywhere, should it be?
>
> Thanks.
>
> --bijan
>
>
>
>
--
Jens Axboe
