On 8/28/22 20:25, gumi@xxxxxxxxxxxxxxxxx wrote: > This problem occurs on kernel version 5.10, and i read this commit you > mentioned. The problem I observed is not a problem of req re-used > fixed by commit 2e315dc07df0, but a different problem. The specific > scene is this: A new IO has called blk_mq_start_request() to start > sending, and an instruction out of sequence occurs between > blk_add_timer() and WRITE_ONCE(rq->state,MQ_RQ_IN_FLIGHT) in > blk_mq_start_request(), so the req->state is set to MQ_RQ_IN_FLIGHT, > but req->deadline still 0, and at this very moment, timeout > handler(blk_mq_check_expired()) check if this new IO times out, this > condition(if (time_after_eq(jiffies, deadline)) in > blk_mq_req_expired() called by blk_mq_check_expired()) will is true. > The end result is that this new IO is considered to have timed out. I > looked at the latest kernel code and the problem persists, do you > agree with my analysis process? It seems unlikely to me that the above analysis is correct. If this problem would occur with recent kernel versions, I think that it would already have been reported by other Linux users. Thanks, Bart. --- Hi Bart, First of all, this problem is not easy to be tested. We have tested it hundreds of times, and the recurrence is low probability. Basically, it needs to run continuously for 15-20 days under the high pressure test. After analyzing the reason, we modified it according to the method of V1, and continued to test for more than 30 days, and this problem did not appear. Finally I decided to submit this patch to upstream. According to our code analysis, this problem scenario is one that may occur under polar probability, please re-examine my analysis process. Thanks, Gu Mi
