Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp957687imm; Fri, 22 Jun 2018 08:04:45 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLs+WDmJroVXCou3i1Hmxg1WPpxvFyjWCrZV5cFKdtORbcPSDvUdfMGBFMNzoymF2XI+Os6 X-Received: by 2002:a17:902:6bca:: with SMTP id m10-v6mr2139674plt.6.1529679885542; Fri, 22 Jun 2018 08:04:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529679885; cv=none; d=google.com; s=arc-20160816; b=Me5I4V5SRMEI8Odcb+TJ74HSAaus/IWeV2H7XMhuD2TFBHgTIx232SdLF8b/B6sW9D xe4l3YvoGsAqa5nObhB/PiswVjlYOGhV3tPzbahar3X1kPOztedZKBAMPM9sFBAc0aXK +rQ2VdYF03reN5BbohPraetVSfQ18wywSfATn9dIktS9MO/rQ87ri4mPAcGXNfsfvUQN bT1OJbjNz3VdptoY/qugf3IQTF5KQhIV5tOgkSO/Gvd6AxxaRPmjDEQBXJbdR070sofj w1hqffpZwMY8gmT7kssPlpQCL7hUOdedFqaTbbDvCIMvu3qQMF6PHC+sNK3WeT34sekV Lq4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=kVR0E6kDp+X7AC66RBbVeTLrwIYTdh0PSxDH6ohSRdo=; b=0aeg1TI9GrkK9Z0Z4xjytdkz7+srQSy2ZEJCExooMYOkpEOZnbx1ZpI+mW9ZBYPwaA pS1UX7bJRnZtuhwrQm6uMQjfnGl7qa9gg3gaCEUk+o8iw9NJa74vx0oUdU71OhSk/RmJ Rz9IppXgYn9irh4OYoGEax9i15tFTsfyfdtRVotFQNbSf/jd6xYPDa77+hX0j8C9sXnj PuZCo0cVVCfRhlEM82+6qITN0U33nUjX8N80tR4CBa2vPK516vgMw9LXTOqgYhq0YpBA mfh27yyvxiTNLKwqOgHMfUEc38JQD+md4OQXXIAMH6oSYTFlSs1V2ed2+Hkx7TPhzhpU JpvQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k1-v6si6353271pgc.502.2018.06.22.08.04.11; Fri, 22 Jun 2018 08:04:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933549AbeFVPBU (ORCPT + 99 others); Fri, 22 Jun 2018 11:01:20 -0400 Received: from verein.lst.de ([213.95.11.211]:57019 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932950AbeFVPBS (ORCPT ); Fri, 22 Jun 2018 11:01:18 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id F400268E45; Fri, 22 Jun 2018 17:10:43 +0200 (CEST) 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 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.