From: <gumi@linux.alibaba.com>
To: "'Bart Van Assche'" <bvanassche@acm.org>, <axboe@kernel.dk>,
<damien.lemoal@opensource.wdc.com>
Cc: <linux-block@vger.kernel.org>
Subject: Re: [PATCH v2] block: I/O error occurs during SATA disk stress test
Date: Mon, 29 Aug 2022 12:07:35 +0800 [thread overview]
Message-ID: <000401d8bb5c$df344640$9d9cd2c0$@linux.alibaba.com> (raw)
On 8/28/22 20:25, gumi@linux.alibaba.com 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
next reply other threads:[~2022-08-29 4:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 4:07 gumi [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-08-29 4:11 [PATCH v2] block: I/O error occurs during SATA disk stress test gumi
2022-08-29 3:25 gumi
2022-08-29 3:30 ` Bart Van Assche
2022-08-26 3:25 gumi
2022-08-26 13:36 ` Jens Axboe
2022-08-26 16:06 ` Bart Van Assche
2022-08-26 19:40 ` Jens Axboe
2022-08-25 7:09 Gu Mi
2022-08-25 17:18 ` Bart Van Assche
2022-08-26 21:15 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000401d8bb5c$df344640$9d9cd2c0$@linux.alibaba.com' \
--to=gumi@linux.alibaba.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=damien.lemoal@opensource.wdc.com \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.