On 2022/08/24 4:36, Gu Mi wrote: > The problem occurs in two async processes, One is when a new IO > calls the blk_mq_start_request() interface to start sending,The other > is that the block layer timer process calls the blk_mq_req_expired > interface to check whether there is an IO timeout. > > When an instruction out of sequence occurs between blk_add_timer > and WRITE_ONCE(rq->state,MQ_RQ_IN_FLIGHT) in the interface > blk_mq_start_request,at this time, the block timer is checking the > new IO timeout, Since the req status has been set to MQ_RQ_IN_FLIGHT > and req->deadline is 0 at this time, the new IO will be misjudged as > a timeout. > > Our repair plan is for the deadline to be 0, and we do not think > that a timeout occurs. At the same time, because the jiffies of the > 32-bit system will be reversed shortly after the system is turned on, > we will add 1 jiffies to the deadline at this time. > > Signed-off-by: Gu Mi <gumi@xxxxxxxxxxxxxxxxx> > --- > block/blk-mq.c | 2 ++ > block/blk-timeout.c | 4 ++++ > 2 files changed, 6 insertions(+) > > diff --git a/block/blk-mq.c b/block/blk-mq.c > index 4b90d2d..6defaa1 100644 > --- a/block/blk-mq.c > +++ b/block/blk-mq.c > @@ -1451,6 +1451,8 @@ static bool blk_mq_req_expired(struct request *rq, unsigned long *next) > return false; > > deadline = READ_ONCE(rq->deadline); > + if (unlikely(deadline == 0)) > + return false; > if (time_after_eq(jiffies, deadline)) Use time_after() instead of time_after_eq() ? Then the above change would not be needed. > return true; > > diff --git a/block/blk-timeout.c b/block/blk-timeout.c > index 1b8de041..6fc5088 100644 > --- a/block/blk-timeout.c > +++ b/block/blk-timeout.c > @@ -140,6 +140,10 @@ void blk_add_timer(struct request *req) > req->rq_flags &= ~RQF_TIMED_OUT; > > expiry = jiffies + req->timeout; > +#ifndef CONFIG_64BIT > +/* In case INITIAL_JIFFIES wraps on 32-bit */ > + expiry |= 1UL; > +#endif time_after() and friends should handle the overflow. Why is this change needed ? > WRITE_ONCE(req->deadline, expiry); > > /* -- Damien Le Moal Western Digital Research
