[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84a5b54c318b130f47775747d37dc139c27ebda7.camel@wdc.com>
Date: Thu, 21 Jun 2018 18:21:09 +0000
From: Bart Van Assche <Bart.VanAssche@....com>
To: "hch@....de" <hch@....de>,
"jianchao.w.wang@...cle.com" <jianchao.w.wang@...cle.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"axboe@...nel.dk" <axboe@...nel.dk>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"josef@...icpanda.com" <josef@...icpanda.com>,
"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
"keith.busch@...el.com" <keith.busch@...el.com>
Subject: Re: [PATCH 0/5]stop normal completion path entering a timeout req
On Thu, 2018-06-21 at 10:19 +0200, Christoph Hellwig wrote:
> On Thu, Jun 21, 2018 at 09:43:26AM +0800, jianchao.wang wrote:
> > So we have to preserve the ability of block layer that it could prevent
> > IO completion path from entering a timeout request.
> >
> > With scsi-debug module, I tried to simulate a scenario where timeout and IO
> > completion path could occur concurrently, the system ran into crash easily.
>
> Trace, please. With the latest kernel. I'm not saying that there
> is nothing to fix, but the mode of never completing once timeout
> requests as currently done is SCSI is clearly broken.
That's not how the SCSI core works.
Bart.
Powered by blists - more mailing lists