On 2020/10/14 6:36, Sagi Grimberg wrote:
This may just reduce the probability. The concurrency of timeout and teardown will cause the same request
be treated repeatly, this is not we expected.
That is right, not like SCSI, NVME doesn't apply atomic request completion, so
request may be completed/freed from both timeout & nvme_cancel_request().
.teardown_lock still may cover the race with Sagi's patch because teardown
actually cancels requests in sync style.
In extreme scenarios, the request may be already retry success(rq state change to inflight).
Timeout processing may wrongly stop the queue and abort the request.
teardown_lock serialize the process of timeout and teardown, but do not avoid the race.
It might not be safe.
Not sure I understand the scenario you are describing.
what do you mean by "In extreme scenarios, the request may be already retry success(rq state change to inflight)"?
What will retry the request? only when the host will reconnect
the request will be retried.
If irq interrupt the timeout work, and cause the timeout work pause long time(more than 100ms).
The reconnect may already success, and start requests. And then timeout work continue run to
wrongly stop queue and cancel the request.
The probability of this happening is very low.
We can call nvme_sync_queues in the last part of the teardown, but
I still don't understand the race here.
.
