Received: by 10.223.176.5 with SMTP id f5csp1075336wra; Fri, 2 Feb 2018 10:44:41 -0800 (PST) X-Google-Smtp-Source: AH8x224KL6ogpuAlB3GcRiRdcjFHPloIjiSMyB22waS9Ph/Li0x9B8TJE8d30E6hz3/tgnvFjjGd X-Received: by 2002:a17:902:e85:: with SMTP id 5-v6mr29997131plx.208.1517597081203; Fri, 02 Feb 2018 10:44:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517597081; cv=none; d=google.com; s=arc-20160816; b=OhAL71EilWCQ1vlwNsbr6tqPbVdonHxAXejNYtXPCufYhMexyqTcQha3THPrtRS3e2 +0OTr2w9+oXGDBqgW9WfMUIi2/ZsxRRv3d0y+WdIgyJlkBHubKa03qptOlIvjsPqdt7q o0s/998QOlnO1Yj1G/Wvu8Q/4e47yQYjPLfpTTI0hhwJkiDy5ZuIMRHtAcvwqFrAW/0c ujpL9sMaWMHd4pO7Io158132MtAkDWCpfgBU9wFA8fsX0iXohiJGeyEUHSAYZD8OyIeg 2FwWLEcUl6rENDmX13BNaNXpWEPeWb6pLMJYcEievoXkxtmfK8fI4oLaia6cIpUglqbG x0Xg== 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=POsGmozFZ9B+A14e2ww3Fg6NPhGw+AzcBARgwNt46eA=; b=V8U+BauH8MvGe1r+2rPfJSkQV1K+A3eqgxHvb2Z5I2BXwlqS7QxyjnUmVn4HTpJnSk ifHf7wt31rjnEX/zJhFGN9e30Zj4oAxklCy5zPoaFTtAr24iuia8CI3LMim7jbiZGxg9 H41eP9MGGX47urQK2IaMNJYSwCsKp81f0S1lZyDGJ7A14bQGdeMR/7eHlhIradNG6AHJ NJPc1fvKdFklj9CDTdVOuX11e1hkzUvbjvyhkFmoNNzd5uZN0pdZ9bW4S/sSg47nyw7M 49o27aTL99fPEtJNuWyCU61ZPuULyoYliA/zzuq58amJ62yjwHuXJTyThTUfu4X++RLs SZjA== 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 j61-v6si2266991plb.108.2018.02.02.10.44.26; Fri, 02 Feb 2018 10:44:41 -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 S1755160AbeBBSmY (ORCPT + 99 others); Fri, 2 Feb 2018 13:42:24 -0500 Received: from mga02.intel.com ([134.134.136.20]:60444 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751907AbeBBSmS (ORCPT ); Fri, 2 Feb 2018 13:42:18 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2018 10:42:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,450,1511856000"; d="scan'208";a="200751028" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by fmsmga005.fm.intel.com with ESMTP; 02 Feb 2018 10:42:16 -0800 Date: Fri, 2 Feb 2018 11:46:05 -0700 From: Keith Busch To: Jianchao Wang Cc: axboe@fb.com, hch@lst.de, sagi@grimberg.me, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] nvme-pci: move clearing host mem behind stopping queues Message-ID: <20180202184605.GJ24417@localhost.localdomain> References: <1517554849-7802-1-git-send-email-jianchao.w.wang@oracle.com> <1517554849-7802-2-git-send-email-jianchao.w.wang@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1517554849-7802-2-git-send-email-jianchao.w.wang@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, Feb 02, 2018 at 03:00:44PM +0800, Jianchao Wang wrote: > Move clearing host mem behind stopping queues. Prepare for > following patch which will grab all the outstanding requests. > > Signed-off-by: Jianchao Wang This one makes sense, though I would alter the change log to something like: This patch quiecses new IO prior to disabling device HMB access. A controller using HMB may be relying on it to efficiently complete IO commands. Reviewed-by: Keith Busch > --- > drivers/nvme/host/pci.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c > index 6fe7af0..00cffed 100644 > --- a/drivers/nvme/host/pci.c > +++ b/drivers/nvme/host/pci.c > @@ -2186,7 +2186,10 @@ static void nvme_dev_disable(struct nvme_dev *dev, bool shutdown) > if (!dead) { > if (shutdown) > nvme_wait_freeze_timeout(&dev->ctrl, NVME_IO_TIMEOUT); > + } > + nvme_stop_queues(&dev->ctrl); > > + if (!dead) { > /* > * If the controller is still alive tell it to stop using the > * host memory buffer. In theory the shutdown / reset should > @@ -2195,11 +2198,6 @@ static void nvme_dev_disable(struct nvme_dev *dev, bool shutdown) > */ > if (dev->host_mem_descs) > nvme_set_host_mem(dev, 0); > - > - } > - nvme_stop_queues(&dev->ctrl); > - > - if (!dead) { > nvme_disable_io_queues(dev); > nvme_disable_admin_queue(dev, shutdown); > } > -- > 2.7.4