Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp854666imm; Wed, 13 Jun 2018 09:16:52 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKEGruZmTHAjKisF6UXZFXhXuyX8ZyuCfaYnVTEsPvqwaAb9KXbOToL1fUnBIh7rMbscePT X-Received: by 2002:a17:902:768a:: with SMTP id m10-v6mr5810028pll.293.1528906611994; Wed, 13 Jun 2018 09:16:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528906611; cv=none; d=google.com; s=arc-20160816; b=jTpi6IYQkacw8SKOtSQETcEEtTc52d6NvOz8KWLNV/r4pQPHq7dmKVVoCcWDpDaC1i z5mDlwZ89gO8Axh0Br1DRolDI5dNHB7VCL7xpQOwZ7GPsZj3++8pGucoT6g1oFC8Hjj2 OAZDJh4DleuDy/LLwQCbdXr8gRC84Oxm7dWM0PkHHxj7l19T3PFXKsO88ZwUxpyB15jS AeYd9E2/j4/2XuhY7ADvbZGrDQP3UkIJv8yd2MecKqxXNkgZO62W7Jz1xbRGQ6Wbg90L 5p2EPDqFZwp+DOkxSkwbjDvL+XPpXbZ+8voo7NwmAlQqEJx3bgCWE9geJfqjNWQL73oo W1zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=YGn9Ev7Dbt4igNgeByDoMlBgRZCnTjRmNPxP4zcKlHU=; b=t32aTHB6E3s/kDM55H6vVGcsmitDytApj46C04kHtbr7H2QF3kQ7ZagYGtZJjwcf7x i0wPJER8xZKo8bd30xZeipI346Bfg08kRDmoi2uT62i5pn4dt784yN3iR0CMAFJuQ644 Qlpvqvbj37uzVs4yb3vMmS+6/yyV/sohmCy3NLMVLHk8QXDVKFB8Otnj4DD8su1rdLMm 0PvZZOu7fyiJ7CrJCKyDMWMblf0m1l6fLtzBNfY5iDMpok7nsUZHtMsY9JpIuJm+SPjh 32YAGj7SXLK8GBVi+BwlUkl/gsM9t/ydd+k2IDd0By837mEPJffKYtsDUgr2x3sW/3kh Rrog== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h89-v6si3126071pld.378.2018.06.13.09.16.37; Wed, 13 Jun 2018 09:16:51 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934622AbeFMQOm (ORCPT + 99 others); Wed, 13 Jun 2018 12:14:42 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:47328 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754498AbeFMQOl (ORCPT ); Wed, 13 Jun 2018 12:14:41 -0400 Received: from [148.252.241.226] (helo=xylophone) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1fT8Pr-0002eL-2i; Wed, 13 Jun 2018 17:14:35 +0100 Message-ID: <1528906474.2289.155.camel@codethink.co.uk> Subject: Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails From: Ben Hutchings To: Jianchao Wang , Keith Busch Cc: stable@vger.kernel.org, Sasha Levin , Greg Kroah-Hartman , linux-kernel@vger.kernel.org Date: Wed, 13 Jun 2018 17:14:34 +0100 In-Reply-To: <20180528100214.621806271@linuxfoundation.org> References: <20180528100202.045206534@linuxfoundation.org> <20180528100214.621806271@linuxfoundation.org> Organization: Codethink Ltd. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-05-28 at 12:01 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > ------------------ > > From: Jianchao Wang > > [ Upstream commit f25a2dfc20e3a3ed8fe6618c331799dd7bd01190 ] > > This patch fixes nvme queue cleanup if requesting an IRQ handler for > the queue's vector fails. It does this by resetting the cq_vector to > the uninitialized value of -1 so it is ignored for a controller reset. > > Signed-off-by: Jianchao Wang > [changelog updates, removed misc whitespace changes] > Signed-off-by: Keith Busch > Signed-off-by: Sasha Levin > Signed-off-by: Greg Kroah-Hartman > --- >  drivers/nvme/host/pci.c |    5 ++++- >  1 file changed, 4 insertions(+), 1 deletion(-) > > --- a/drivers/nvme/host/pci.c > +++ b/drivers/nvme/host/pci.c > @@ -1583,7 +1583,7 @@ static int nvme_create_queue(struct nvme >   nvmeq->cq_vector = qid - 1; >   result = adapter_alloc_cq(dev, qid, nvmeq); >   if (result < 0) > - return result; > + goto release_vector; >   >   result = adapter_alloc_sq(dev, qid, nvmeq); >   if (result < 0) > @@ -1597,9 +1597,12 @@ static int nvme_create_queue(struct nvme >   return result; >   >   release_sq: > + dev->online_queues--; This addition looks wrong. dev->online_queues is incremented by nvme_init_queue(), but this function only calls that at a point where it is sure to succeed. So why would a failure path need to decrement it? Ben. >   adapter_delete_sq(dev, qid); >   release_cq: >   adapter_delete_cq(dev, qid); > + release_vector: > + nvmeq->cq_vector = -1; >   return result; >  } >   > > > -- Ben Hutchings, Software Developer   Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom