Received: by 10.223.176.46 with SMTP id f43csp552443wra; Thu, 18 Jan 2018 22:04:19 -0800 (PST) X-Google-Smtp-Source: ACJfBot9B7jfSaFE/rL60NKkWzbax1tmSY4w+o6JzwIxGDav616dBOl9d5XzvBVKoIj2/r1gj72r X-Received: by 10.99.157.72 with SMTP id i69mr3643019pgd.300.1516341859374; Thu, 18 Jan 2018 22:04:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516341859; cv=none; d=google.com; s=arc-20160816; b=Y31nRdXvl8piFPqSsUuB9EudBrj+6y70l8Z5TQLBP5HWtDNq46qpg3eiKjeHmMtC8E D72a7xoQQIDQBYyPlCQkOwBZa3Ec51OtK4Wdi/LyOPG7w4UdizgHCYr9VWwvWMmBXd5J 4Gn4w5eyRB9o2u8qML5pRbj468kIRyqmM6WKal1V/lwMDF7ejGU101/UysoE/FSf34Ki 1whjaiWrTxPirPM6l8ZFQyePmVGmL/7YP5FqCGEnqjeR6eebHz3YuNQCpMZonnDCQILO pD6LNgIjk38L/bhrUc8IRT3L6hsg/EoRAIG2ANy4n1V+R88zkBkIDI/A0SaXvE68AARr 5XAg== 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=BEGL7rgrOf3zTcs8ym8Oaqt9kBrnD7fRSFaviCHaj5U=; b=g6DV5Hgp3ipSanytaQShG85jrEk/0o2idwcl14AMEIxiya/k7/fbVHwYJ5jGRQdXdA DUC1kCY9zq44NhEhCZdgMLWcaPI8ppBLVIlBPUBbCvw6c8SZ7+kBtUPCbtyvHzS+vZv7 rsrtwb8tNVZwzSee1PJi6B7joGL2R16rqksyS4G4Q9jK8eu/n1anwBPSTRqQFc3abi6H EV6dER4Q5TgRzWx46Z9Dcj/F3wURj6XyE3dDdFZlJfrA0kzzHd1SiQw1ogWgWm12CZ/3 OR2bXUBOcg63sVL7ob8qhGFVmiCxslS8pETHtJ4kj46k9fLRJuUtA+Hb7I7TqnvkoCIG Jc/w== 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 i90si8541068pfd.147.2018.01.18.22.04.05; Thu, 18 Jan 2018 22:04:19 -0800 (PST) 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 S1753799AbeASGCH (ORCPT + 99 others); Fri, 19 Jan 2018 01:02:07 -0500 Received: from mga01.intel.com ([192.55.52.88]:2713 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751282AbeASGCD (ORCPT ); Fri, 19 Jan 2018 01:02:03 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2018 22:02:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,380,1511856000"; d="scan'208";a="24611576" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by orsmga001.jf.intel.com with ESMTP; 18 Jan 2018 22:02:01 -0800 Date: Thu, 18 Jan 2018 23:05:21 -0700 From: Keith Busch To: "jianchao.wang" Cc: axboe@fb.com, hch@lst.de, sagi@grimberg.me, maxg@mellanox.com, james.smart@broadcom.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V5 2/2] nvme-pci: fixup the timeout case when reset is ongoing Message-ID: <20180119060521.GD12043@localhost.localdomain> References: <1516270202-8051-1-git-send-email-jianchao.w.wang@oracle.com> <1516270202-8051-3-git-send-email-jianchao.w.wang@oracle.com> <20180119045944.GC12043@localhost.localdomain> <0b74b36d-ecb5-e9e2-2900-6dc9c9699658@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b74b36d-ecb5-e9e2-2900-6dc9c9699658@oracle.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 19, 2018 at 01:55:29PM +0800, jianchao.wang wrote: > On 01/19/2018 12:59 PM, Keith Busch wrote: > > On Thu, Jan 18, 2018 at 06:10:02PM +0800, Jianchao Wang wrote: > >> + * - When the ctrl.state is NVME_CTRL_RESETTING, the expired > >> + * request should come from the previous work and we handle > >> + * it as nvme_cancel_request. > >> + * - When the ctrl.state is NVME_CTRL_RECONNECTING, the expired > >> + * request should come from the initializing procedure such as > >> + * setup io queues, because all the previous outstanding > >> + * requests should have been cancelled. > >> */ > >> - if (dev->ctrl.state == NVME_CTRL_RESETTING) { > >> - dev_warn(dev->ctrl.device, > >> - "I/O %d QID %d timeout, disable controller\n", > >> - req->tag, nvmeq->qid); > >> - nvme_dev_disable(dev, false); > >> + switch (dev->ctrl.state) { > >> + case NVME_CTRL_RESETTING: > >> + nvme_req(req)->status = NVME_SC_ABORT_REQ; > >> + return BLK_EH_HANDLED; > >> + case NVME_CTRL_RECONNECTING: > >> + WARN_ON_ONCE(nvmeq->qid); > >> nvme_req(req)->flags |= NVME_REQ_CANCELLED; > >> return BLK_EH_HANDLED; > >> + default: > >> + break; > >> } > > > > The driver may be giving up on the command here, but that doesn't mean > > the controller has. We can't just end the request like this because that > > will release the memory the controller still owns. We must wait until > > after nvme_dev_disable clears bus master because we can't say for sure > > the controller isn't going to write to that address right after we end > > the request. > > > Yes, but the controller is going to be reseted or shutdown at the moment, > even if the controller accesses a bad address and goes wrong, everything will > be ok after reset or shutdown. :) Hm, I don't follow. DMA access after free is never okay.