Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp690417imm; Wed, 13 Jun 2018 06:56:41 -0700 (PDT) X-Google-Smtp-Source: ADUXVKITdRiwEJmyFuXSuwA/WiHEZKcbfyZo9c7JY4Uj8QRMwVW6mvw8pVmcWZB1nHkAumccGVaQ X-Received: by 2002:a63:2bc4:: with SMTP id r187-v6mr4201634pgr.231.1528898201686; Wed, 13 Jun 2018 06:56:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528898201; cv=none; d=google.com; s=arc-20160816; b=ay3xIGZzmDe1vsCyo43Avf0qw9juHclYzEnVznRELL9XUv39XpkqWdbJhUVQOUcXdv +Yb64b6kB1crAI+zeSmuM2R2KXyJVzJjtbMCm3NCQkK29mRvds0ANA+xhW+iKNcTGrpt UfB+JlcJlzPVCfUQ9iM6fG3EAyM6VO7evcNREJ9Vb6mdHYV/5ot+oNSbDAXbxFManVY8 RCWJCQsGhC7WBjOhyaRWZAPVqA7wWIJ7K1mo3pejytZh9uOEpvpA+akUltEXoCUDJq3C ZD6nHMZCD1Lce2a3SI0GR5XEUmT4SsRFitAeBCYyeAexCdqUnQsqLk9rk+d+vsjJj/iS ZL1w== 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=2xwIt8KQ11pkMZR4vu8RoMP0dLt0SdKby1hTv9RB8AI=; b=zZjMgacLX4Bq+YrufcQWyswLBxu6ghrG8cWWxYId80IYSlyseSH5NTjHxu0WzseM2v e49PXKb/cCvzvRpCA7TRarZjhTi8p3iCPKdkPoJVi8wwkG8B5wjfWmhi4+f9KkKJ7tZp fU6U+v2f40IQ1aMBrv4DFk+kYaGAQvA81na5SskFcogkbzmWgMRArPonnZvprEZR2Oo2 sxyJvrxzs36/na/AKBENktrqIcbC71iLZdvxRuFSdfuvOsdoLJ/07xcebE2HQ13gK9fg NDnL2PJAk3ucT9tw6ZknO+FW5qHU2XpggWyiAdZ5UIjfbu8zNIRDaGWRveK5uAZc38Q6 A6Jg== 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 v28-v6si2381479pgc.531.2018.06.13.06.56.26; Wed, 13 Jun 2018 06:56:41 -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 S935692AbeFMN4A (ORCPT + 99 others); Wed, 13 Jun 2018 09:56:00 -0400 Received: from verein.lst.de ([213.95.11.211]:41106 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935185AbeFMNz6 (ORCPT ); Wed, 13 Jun 2018 09:55:58 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id 7FAAC68E46; Wed, 13 Jun 2018 16:04:11 +0200 (CEST) Date: Wed, 13 Jun 2018 16:04:11 +0200 From: "hch@lst.de" To: "jianchao.wang" Cc: Bart Van Assche , "randrianasulu@gmail.com" , "rdunlap@infradead.org" , "linux-kernel@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "hch@lst.de" , "linux-block@vger.kernel.org" Subject: Re: kernel BUG at drivers/scsi/scsi_error.c:197! - git 4.17.0-x64-08428-g7d3bf613e99a Message-ID: <20180613140411.GA32701@lst.de> References: <201806091606.51078.randrianasulu@gmail.com> <025bf705-15b0-65e5-4b16-6c91d41c1730@infradead.org> <40617b19667b3c1302f8a903c19f2fa2f409b12a.camel@wdc.com> <5ca74fb7-af70-31c3-0e3f-bace058e5a57@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ca74fb7-af70-31c3-0e3f-bace058e5a57@oracle.com> 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 > 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.