From: "hch@lst.de" <hch@lst.de>
To: "jianchao.wang" <jianchao.w.wang@oracle.com>
Cc: Bart Van Assche <Bart.VanAssche@wdc.com>,
"randrianasulu@gmail.com" <randrianasulu@gmail.com>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"hch@lst.de" <hch@lst.de>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: kernel BUG at drivers/scsi/scsi_error.c:197! - git 4.17.0-x64-08428-g7d3bf613e99a
Date: Wed, 13 Jun 2018 16:04:11 +0200 [thread overview]
Message-ID: <20180613140411.GA32701@lst.de> (raw)
In-Reply-To: <5ca74fb7-af70-31c3-0e3f-bace058e5a57@oracle.com>
> I suspect this is due to we could expire a same request twice or even more.
> For scsi mid-layer, it return BLK_EH_DONE from .timeout, in fact, the request is not
> completed there, but just queue a delayed abort_work (HZ/100). If the blk_mq_timeout_work
> runs again before the abort_work, the request will be timed out again, because there is not
> any mark on it to identify this request has been timed out.
>
> Would please try the patch attached on to see whether this issue could be fixed ?
> (this patch only works for scsi device currently)
The patch isn't really going to work without a caller of your new
__blk_mq_complete_request helper, is it?
Either way the concept of doing error handling without quiescing the
queue just looks bogus to me and will end up with some sort of race
here or there.
next prev parent reply other threads:[~2018-06-13 13:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-09 13:06 kernel BUG at drivers/scsi/scsi_error.c:197! - git 4.17.0-x64-08428-g7d3bf613e99a Andrew Randrianasulu
2018-06-09 15:02 ` Randy Dunlap
2018-06-12 15:28 ` Bart Van Assche
2018-06-13 1:28 ` Andrew Randrianasulu
2018-06-13 4:03 ` jianchao.wang
2018-06-13 7:38 ` Andrew Randrianasulu
2018-06-13 14:04 ` hch [this message]
2018-06-13 14:08 ` Bart Van Assche
2018-06-13 14:35 ` hch
2018-06-14 7:49 ` jianchao.wang
2018-06-14 8:32 ` hch
2018-06-14 3:12 ` jianchao.wang
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=20180613140411.GA32701@lst.de \
--to=hch@lst.de \
--cc=Bart.VanAssche@wdc.com \
--cc=jianchao.w.wang@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=randrianasulu@gmail.com \
--cc=rdunlap@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox