Received: by 10.223.176.5 with SMTP id f5csp180352wra; Tue, 30 Jan 2018 09:49:38 -0800 (PST) X-Google-Smtp-Source: AH8x224cwEWpgbxthn0CF7bLQEso/kdzUrPlKtLoHe7lhuNeP+KLFs4vScoVHye4sNi5HXkUHVBM X-Received: by 10.98.246.8 with SMTP id x8mr30719020pfh.234.1517334578097; Tue, 30 Jan 2018 09:49:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517334578; cv=none; d=google.com; s=arc-20160816; b=X5Xhnkn1oQRc46S7gyuyTeGZbK7+vHFTaO2eFKNm4XpzA0PACEhVWr9EIZxFV8QWSG uTmlo1AAiNXZfLotTa+e2WHuel8C+qPbPE6uhNShvZo0VLdkAVz07Z/64VCsOmSfAvbL e9XBFpWt6IP6nw2p47JcHEOY2Vhqvbz/92qL+UGO/POLDTl45Ojp3Zt79IADlJFYpqAy FfBLvwYa+jYYJIDpFpdENzWazA7Qm1PTMlgkPbcjgmPIZ6ZaY4mZJomcn5SKc9ao0vL+ hmpMxBDXXvQyvt5bdr1rskzGzDrf8XEBHZtdxQ1NWCEcGZ07rChCJa21IBMmS1Ujl1g3 DpFQ== 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=+bSf/lXLIZfHtQiEtWMTYbyEDP+vLI9dt/8kxgW67iw=; b=RN+/FoN7NsJ34DB1+LbuBbfflGn809+8X458F1Drix1fC6T4BnCNwnsP7IwQPBMpVV F58N2F/bFYB/rqQmUnrZV2u+Pw9Nquxt4b8fnKeYKUwl3/fd9f15yjXlnufaeChmy4lF ZlwzcPdov47Mah04Sf02/bm3p2xs7y3XOROL8s/DEO6csyBHgTxXbXGuBtmcZmJGvyCB 51i9gfaZohxqeXP80KDi1LojX10Fi1fDTbw8SP5MR4iObIP6o7WNwKuawIwRidqjYDbQ bk0zmhyE0qMaxLQdkmDKaUWez56Kk0dv5NGfm7rpMFPhR1BErx20nnS8z2L8ndesoG2t SZCw== 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 e25si2424887pgn.782.2018.01.30.09.49.23; Tue, 30 Jan 2018 09:49:38 -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 S1753313AbeA3QJV (ORCPT + 99 others); Tue, 30 Jan 2018 11:09:21 -0500 Received: from mga02.intel.com ([134.134.136.20]:33912 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751836AbeA3QJU (ORCPT ); Tue, 30 Jan 2018 11:09:20 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2018 08:09:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,435,1511856000"; d="scan'208";a="14072648" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by fmsmga007.fm.intel.com with ESMTP; 30 Jan 2018 08:09:19 -0800 Date: Tue, 30 Jan 2018 09:13:02 -0700 From: Keith Busch To: "jianchao.wang" Cc: Sagi Grimberg , axboe@fb.com, hch@lst.de, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nvme-pci: use NOWAIT flag for nvme_set_host_mem Message-ID: <20180130161302.GA27205@localhost.localdomain> References: <1517195255-21832-1-git-send-email-jianchao.w.wang@oracle.com> <20180129160145.GA25515@localhost.localdomain> <1b7d3700-945f-9272-b6aa-d2ebeaf0cb1e@grimberg.me> <20180129201716.GB25515@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue, Jan 30, 2018 at 11:41:07AM +0800, jianchao.wang wrote: > Another point that confuses me is that whether nvme_set_host_mem is necessary > in nvme_dev_disable ? > As the comment: > ---- > /* > * If the controller is still alive tell it to stop using the > * host memory buffer. In theory the shutdown / reset should > * make sure that it doesn't access the host memoery anymore, > * but I'd rather be safe than sorry.. > */ > if (dev->host_mem_descs) > nvme_set_host_mem(dev, 0); > ---- > It is to avoid accessing to host memory from controller. But the host memory is just > freed when nvme_remove. It looks like we just need to do this in nvme_remove. > For example: > ----- > @@ -2553,6 +2545,14 @@ static void nvme_remove(struct pci_dev *pdev) > flush_work(&dev->ctrl.reset_work); > nvme_stop_ctrl(&dev->ctrl); > nvme_remove_namespaces(&dev->ctrl); > + /* > + * If the controller is still alive tell it to stop using the > + * host memory buffer. In theory the shutdown / reset should > + * make sure that it doesn't access the host memoery anymore, > + * but I'd rather be safe than sorry.. > + */ > + if (dev->host_mem_descs) > + nvme_set_host_mem(dev, 0); > nvme_dev_disable(dev, true); > nvme_free_host_mem(dev); > ---- > > If anything missed, please point out. > That's really appreciated. I don't make any such controller, so I can't speak to the necessity of having this here. I just think having it in the controller disabling path is for safety. We want the controller to acknowledge that it has completed any use of the HMB before we make it so it can't access it.