Hi Suwan, apologies for taking so long to come back to this.

On Tue, Aug 2, 2022 at 11:50 PM Kim Suwan [off-list ref] wrote:

Hi Alexandre

On Tue, Aug 2, 2022 at 11:12 AM Alexandre Courbot [off-list ref] wrote:

quoted

 Hi Suwan,

Thanks for the fast reply!

On Tue, Aug 2, 2022 at 1:55 AM Kim Suwan [off-list ref] wrote:

quoted

Hi Alexandre,

Thanks for reporting the issue.

I think a possible scenario is that request fails at
virtio_queue_rqs() and it is passed to normal path (virtio_queue_rq).

In this procedure, It is possible that blk_mq_start_request()
was called twice changing request state from MQ_RQ_IN_FLIGHT to
MQ_RQ_IN_FLIGHT.

I have checked whether virtblk_prep_rq_batch() within
virtio_queue_rqs() ever returns 0, and it looks like it never happens.
So as far as I can tell all virtio_queue_rqs() are processed
successfully - but maybe the request can also fail further down the
line? Is there some extra instrumentation I can do to check that?

I'm looking at one more suspicious code.
If virtblk_add_req() fails within virtblk_add_req_batch(),
virtio_queue_rqs() passes the failed request to the normal path also
(virtio_queue_rq). Then, it can call blk_mq_start_request() twice.

Because I can't reproduce the issue on my vm, Could you test
the below patch?
I defer the blk_mq_start_request() call after virtblk_add_req()
to ensure that we call blk_mq_start_request() after all the
preparations finish.

Your patch seems to solve the problem! I am not seeing the warning
anymore and the block device looks happy.

Let me know if I can do anything else.

Cheers,
Alex.