Received: by 10.223.176.5 with SMTP id f5csp3040415wra; Mon, 29 Jan 2018 07:58:54 -0800 (PST) X-Google-Smtp-Source: AH8x225T2S7ZrJtommXdkM7ON7+fkLRo9S1kTEdnexfnlpmjn9y8bJepXrkWXFBa3G/yzzdzaY2p X-Received: by 10.98.103.209 with SMTP id t78mr27589192pfj.53.1517241534123; Mon, 29 Jan 2018 07:58:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517241534; cv=none; d=google.com; s=arc-20160816; b=hhLtZYYPSlRNDmbOjP/6WgUQ2rRN3AP5fYw2TuOrYWMtWh1e1qVG9OxnCcJwG63ICm YoY/f5oByJeKDHTES8SOrXBX/d5g9hPGdhZj8rlKu6T3aZHVMy7vzlrRcqaVIbiFDGwF fBx9dELHrZiUbLaPSptxqtQqAofqWJu/fBKjk+manmXLR0G0x1HoVxPARQvogCV/SMri TQEk/MX6gL90iqafx7/Hf194YiIzv71qE+AmAtCFdnaOrk7/1Nq5zaJ4j5UVVTfPNMxe b2Gn2JRqpdlEedbzf2ZnMTweES+PaBeVSVIoLvTolZxa/rpOlPTMm62GPDxbjDhPOEGw rO0g== 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=Gqn1ThtM8ruMAWl4/bUyYmXWWQii4iPLoV1wjsI07aY=; b=leXYMalY98z63tq0UJwynXmWpEviGTPKi4n0UZ7Fw0Fn/P/J20tPp9rthh6+6UyIYj M0R7M0w+NxZ38RGE5YXsKaYwUp055enIdQDrbi9xe/pueae0WjHkFxR3Wp2WdiMZxLER Q2DSvDmbW6zMHkHMUOTNPE4YzAOjEHT8617wrdUK40fl2oGGK2Gncemto6p4isW6QoVa vPx+sOT3QhrTbViLTc4lHLGDNDX3wIjS651JraT7NPpTCkaBgyxw/NrPVFPXDb6E0FA7 cKFi4sx0ISVTkIVz34tBTBtIeS2IXmZbOn86RHmkaQir+ZVdoONUmPiR6DraPrEuFrTx Dt/Q== 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 r15si4033674pfb.86.2018.01.29.07.58.39; Mon, 29 Jan 2018 07:58:54 -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 S1751301AbeA2P6H (ORCPT + 99 others); Mon, 29 Jan 2018 10:58:07 -0500 Received: from mga05.intel.com ([192.55.52.43]:15645 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750959AbeA2P6F (ORCPT ); Mon, 29 Jan 2018 10:58:05 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2018 07:58:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,431,1511856000"; d="scan'208";a="25621107" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by fmsmga004.fm.intel.com with ESMTP; 29 Jan 2018 07:58:05 -0800 Date: Mon, 29 Jan 2018 09:01:46 -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] nvme-pci: use NOWAIT flag for nvme_set_host_mem Message-ID: <20180129160145.GA25515@localhost.localdomain> References: <1517195255-21832-1-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: <1517195255-21832-1-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 Mon, Jan 29, 2018 at 11:07:35AM +0800, Jianchao Wang wrote: > nvme_set_host_mem will invoke nvme_alloc_request without NOWAIT > flag, it is unsafe for nvme_dev_disable. The adminq driver tags > may have been used up when the previous outstanding adminq requests > cannot be completed due to some hardware error. We have to depend > on the timeout path to complete the previous outstanding adminq > requests and free the tags. > However, nvme_timeout will invoke nvme_dev_disable and try to > get the shutdown_lock which is held by another context who is > sleeping to wait for the tags to be freed by timeout path. A > deadlock comes up. > > To fix it, let nvme_set_host_mem use NOWAIT flag. > > Signed-off-by: Jianchao Wang Thanks for the fix. It looks like we still have a problem, though. Commands submitted with the "shutdown_lock" held need to be able to make forward progress without relying on a completion, but this one could block indefinitely. > drivers/nvme/host/pci.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c > index 6fe7af0..9532529 100644 > --- a/drivers/nvme/host/pci.c > +++ b/drivers/nvme/host/pci.c > @@ -1736,7 +1736,8 @@ static int nvme_set_host_mem(struct nvme_dev *dev, u32 bits) > c.features.dword14 = cpu_to_le32(upper_32_bits(dma_addr)); > c.features.dword15 = cpu_to_le32(dev->nr_host_mem_descs); > > - ret = nvme_submit_sync_cmd(dev->ctrl.admin_q, &c, NULL, 0); > + ret = __nvme_submit_sync_cmd(dev->ctrl.admin_q, &c, NULL, NULL, 0, 0, > + NVME_QID_ANY, 0, BLK_MQ_REQ_NOWAIT); > if (ret) { > dev_warn(dev->ctrl.device, > "failed to set host mem (err %d, flags %#x).\n", > --