From: Ming Lei <ming.lei@redhat.com>
To: luojiaxing <luojiaxing@huawei.com>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
Jens Axboe <axboe@kernel.dk>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
john.garry@huawei.com
Subject: Re: rq pointer in tags->rqs[] is not cleared in time and make SCSI error handle can not be triggered
Date: Thu, 26 Aug 2021 15:29:45 +0800 [thread overview]
Message-ID: <YSdCfSeEv9s9OUMX@T590> (raw)
In-Reply-To: <fe5cf6c4-ce5e-4a0f-f4ab-5c10539492cb@huawei.com>
On Thu, Aug 26, 2021 at 11:00:34AM +0800, luojiaxing wrote:
> Dear all:
>
>
> I meet some problem when test hisi_sas driver(under SCSI) based on 5.14-rc4
> kernel, it's found that error handle can not be triggered after
>
> abnormal IO occur in some test with a low probability. For example,
> circularly run disk hardreset or disable all local phy of expander when
> running fio.
>
>
> We add some tracepoint and print to see what happen, and we got the
> following information:
>
> (1).print rq and rq_state at bt_tags_iter() to confirm how many IOs is
> running now.
>
> <4>[ 897.431182] bt_tags_iter: rqs[2808]: 0xffff202007bd3000; rq_state: 1
> <4>[ 897.437514] bt_tags_iter: rqs[3185]: 0xffff0020c5261e00; rq_state: 1
> <4>[ 897.443841] bt_tags_iter: rqs[3612]: 0xffff00212f242a00; rq_state: 1
> <4>[ 897.450167] bt_tags_iter: rqs[2808]: 0xffff00211d208100; rq_state: 1
> <4>[ 897.456492] bt_tags_iter: rqs[2921]: 0xffff00211d208100; rq_state: 1
> <4>[ 897.462818] bt_tags_iter: rqs[1214]: 0xffff002151d21b00; rq_state: 1
> <4>[ 897.469143] bt_tags_iter: rqs[2648]: 0xffff0020c4bfa200; rq_state: 1
>
> The preceding information show that rq with tag[2808] is found in different
> hctx by bt_tags_iter() and with different pointer saved in tags->rqs[].
>
> And tag[2808] own the same pointer value saved in rqs[] with tag[2921]. It's
> wrong because our driver share tag between all hctx, so it's not possible
What is your io scheduler? I guess it is deadline, and can you observe
such issue by switching to none?
The tricky thing is that one request dumped may be re-allocated to other tag
after returning from bt_tags_iter().
>
> to allocate one tag to different rq.
>
>
> (2).check tracepoints(temporarily add) in blk_mq_get_driver_tag() and
> blk_mq_put_tag() to see where this tag is come from.
>
> Line 1322969: <...>-20189 [013] .... 893.427707:
> blk_mq_get_driver_tag: rqs[2808]: 0xffff00211d208100
> Line 1322997: irq/1161-hisi_s-7602 [012] d..1 893.427814:
> blk_mq_put_tag_in_free_request: rqs[2808]: 0xffff00211d208100
> Line 1331257: <...>-20189 [013] .... 893.462663:
> blk_mq_get_driver_tag: rqs[2860]: 0xffff00211d208100
> Line 1331289: irq/1161-hisi_s-7602 [012] d..1 893.462785:
> blk_mq_put_tag_in_free_request: rqs[2860]: 0xffff00211d208100
> Line 1338493: <...>-20189 [013] .... 893.493519:
> blk_mq_get_driver_tag: rqs[2921]: 0xffff00211d208100
>
> As we can see this rq is allocated to tag[2808] once, and finially come to
> tag[2921], but rqs[2808] still save the pointer.
Yeah, we know this kind of handling, but not see it as issue.
>
> There will be no problem until we encounter a rare situation.
>
> For example, tag[2808] is reassigned to another hctx for execution, then
> some IO meet some error.
I guess the race is triggered when 2808 is just assigned, meantime
->rqs[] isn't updated.
>
> Before waking up the error handle thread, SCSI compares the values of
> scsi_host_busy() and shost->host_failed.
>
> If the values are different, SCSI waits for the completion of some I/Os.
> According to the print provided by (1), the return value of scsi_host_busy()
> should be 7 for tag [2808] is calculated twice,
>
> and the value of shost->host_failed is 6. As a result, this two values are
> never equal, and error handle cannot be triggered.
>
>
> A temporary workaround is provided and can solve the problem as:
>
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index 2a37731..e3dc773 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -190,6 +190,7 @@ void blk_mq_put_tag(struct blk_mq_tags *tags, struct
> blk_mq_ctx *ctx,
> BUG_ON(tag >= tags->nr_reserved_tags);
> sbitmap_queue_clear(tags->breserved_tags, tag, ctx->cpu);
> }
> + tags->rqs[tag] = NULL;
> }
>
>
> Since we did not encounter this problem in some previous kernel versions, we
> wondered if the community already knew about the problem or could provide
> some solutions.
Can you try the following patch?
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 86f87346232a..97557ba0737f 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -301,7 +301,7 @@ static bool bt_tags_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data)
return true;
if (!(iter_data->flags & BT_TAG_ITER_STARTED) ||
- blk_mq_request_started(rq))
+ (blk_mq_request_started(rq) && rq->tag == bitnr))
ret = iter_data->fn(rq, iter_data->data, reserved);
if (!iter_static_rqs)
blk_mq_put_rq_ref(rq);
Thanks,
Ming
next prev parent reply other threads:[~2021-08-26 7:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-26 3:00 rq pointer in tags->rqs[] is not cleared in time and make SCSI error handle can not be triggered luojiaxing
2021-08-26 7:29 ` Ming Lei [this message]
2021-08-31 2:27 ` luojiaxing
2021-08-31 8:37 ` Ming Lei
2021-09-01 7:07 ` luojiaxing
2021-09-01 9:36 ` Ming Lei
2021-09-01 9:50 ` Ming Lei
2021-09-06 8:16 ` luojiaxing
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=YSdCfSeEv9s9OUMX@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=john.garry@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=luojiaxing@huawei.com \
--cc=martin.petersen@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox