From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 22 Jun 2018 17:10:43 +0200 From: Christoph Hellwig To: "jianchao.wang" Cc: Christoph Hellwig , Keith Busch , axboe@kernel.dk, martin.petersen@oracle.com, josef@toxicpanda.com, ulf.hansson@linaro.org, linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/5]stop normal completion path entering a timeout req Message-ID: <20180622151043.GA13470@lst.de> References: <1529500964-28429-1-git-send-email-jianchao.w.wang@oracle.com> <20180620181601.GA24145@localhost.localdomain> <20180621081900.GA5183@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-ID: On Thu, Jun 21, 2018 at 04:22:22PM +0800, jianchao.wang wrote: > > 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. > > > > I didn't find the existing method to simulate this. > So I modified the scsi-debug as following patch as install it as following: > modprobe scsi-debug delay=-1 ndelay=-1 > Both 4.17-rc1 and 4.18-rc1 with this patch set could survive from the test. What tree is this against? I can't apply it to either current Linus' tree or 4.17 for that matter. Also I'm not sure this blk_abort_request call is representative of the real world. Drivers do drain their queues before calling it in general, e.g. take a look at ata_eh_set_pending for the probably most common user.