Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5227986yba; Mon, 13 May 2019 07:28:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqzto350KcHU/sjqW5HtOTBGoAqnYOz0Q4lSlWjyHvGg0nrBOctugpwjFqCSiucTqHaQswJp X-Received: by 2002:a63:7c6:: with SMTP id 189mr30871386pgh.247.1557757715193; Mon, 13 May 2019 07:28:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557757715; cv=none; d=google.com; s=arc-20160816; b=dXY9fPlUSYk4ILqBJM/unbcoH4gB8lfNeJD+0B9gIUtXWa17lsv0MyxxCv+me5hJPw UQdXRRQqmOsEwnKQrz04zYQcPSrSPfirWHA+yQg2cmzyRsTqv5mu01WM1xQNfcf8FWrm FQ7ObJVoDK8dgLYoRvmPOgmXGaKN5NMSvS9whrATi4xLoFXWkn1en0EyX/B38hjAdq7i CsH6dnuYWMQwHova7KLpGif9cNehXufzD8KvFOUs3R+Fbd5FiH/PDpxm/YUdkB6As1F0 73DAPNzL3z1Cv4zpK8DX3J/pkEVp6VHmb2fkgS7dRlTvaiYFEbagU3uGbOovDccLjZew 79OQ== 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 :references:in-reply-to:message-id:subject:cc:to:from:date; bh=qUzDQzmnyRbKeNfkFix7gmeXJuYLZwUdqT2koH8W1eI=; b=Jl2outGR4/V5KNWwpXqQwQbhazVGSiYCQf34MXzm7wsj7AalBYxPSxX5J9R8qwO5OY YabShmV4bcJcQTkGkxtBh7Rvpu22gaCUJGqloHD0wuyKw4eoXdyJKT313OKphdeSvTwf KnQXITGYYLqYqnohBFsCO10itUDjpbek3Hb9xcvp18cA274Di3D24ZoBRDoebP8D21Zb zkDUlnh5lP0mpHY3sDSd7IRjR01oLmmkjJ5GMRvpTfCdZUMGk948h+ZEc18G1UTd45EJ Y4vJ007bfJJu/9xwk93VKMA2RPTxtOboxEFxwikCzxNwOrXiZCldK0T7wMTbiKTptqc7 kz/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 q82si19013720pfc.12.2019.05.13.07.28.19; Mon, 13 May 2019 07:28:35 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730596AbfEMOVx (ORCPT + 99 others); Mon, 13 May 2019 10:21:53 -0400 Received: from 4.mo177.mail-out.ovh.net ([46.105.37.72]:44380 "EHLO 4.mo177.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730588AbfEMOVw (ORCPT ); Mon, 13 May 2019 10:21:52 -0400 X-Greylist: delayed 7800 seconds by postgrey-1.27 at vger.kernel.org; Mon, 13 May 2019 10:21:51 EDT Received: from player729.ha.ovh.net (unknown [10.108.54.87]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 0072CF7501 for ; Mon, 13 May 2019 13:56:15 +0200 (CEST) Received: from kaod.org (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player729.ha.ovh.net (Postfix) with ESMTPSA id 1EAF25D72366; Mon, 13 May 2019 11:56:07 +0000 (UTC) Date: Mon, 13 May 2019 13:56:06 +0200 From: Greg Kurz To: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Alistair Popple , Alexey Kardashevskiy Subject: Re: [PATCH] powerpc/powernv/npu: Fix reference leak Message-ID: <20190513135606.7d9a0902@bahia.lan> In-Reply-To: <20190429123659.00c0622b@bahia.lan> References: <155568805354.600470.13376593185688810607.stgit@bahia.lan> <962c1d9e-719c-cb82-cabc-1cf619e1510b@ozlabs.ru> <20190429123659.00c0622b@bahia.lan> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 6583981181895154097 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrleeggdegiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michael, Any comments on this patch ? Should I repost with a shorter comment as suggested by Alexey ? Cheers, -- Greg On Mon, 29 Apr 2019 12:36:59 +0200 Greg Kurz wrote: > On Mon, 29 Apr 2019 16:01:29 +1000 > Alexey Kardashevskiy wrote: > > > On 20/04/2019 01:34, Greg Kurz wrote: > > > Since 902bdc57451c, get_pci_dev() calls pci_get_domain_bus_and_slot(). This > > > has the effect of incrementing the reference count of the PCI device, as > > > explained in drivers/pci/search.c: > > > > > > * Given a PCI domain, bus, and slot/function number, the desired PCI > > > * device is located in the list of PCI devices. If the device is > > > * found, its reference count is increased and this function returns a > > > * pointer to its data structure. The caller must decrement the > > > * reference count by calling pci_dev_put(). If no device is found, > > > * %NULL is returned. > > > > > > Nothing was done to call pci_dev_put() and the reference count of GPU and > > > NPU PCI devices rockets up. > > > > > > A natural way to fix this would be to teach the callers about the change, > > > so that they call pci_dev_put() when done with the pointer. This turns > > > out to be quite intrusive, as it affects many paths in npu-dma.c, > > > pci-ioda.c and vfio_pci_nvlink2.c. > > > > > > afaict this referencing is only done to protect the current traverser > > and what you've done is actually a natural way (and the generic > > pci_get_dev_by_id() does exactly the same), although this looks a bit weird. > > > > Not exactly the same: pci_get_dev_by_id() always increment the refcount > of the returned PCI device. The refcount is only decremented when this > device is passed to pci_get_dev_by_id() to continue searching. > > That means that the users of the PCI device pointer returned by > pci_get_dev_by_id() or its exported variants pci_get_subsys(), > pci_get_device() and pci_get_class() do handle the refcount. They > all pass the pointer to pci_dev_put() or continue the search, > which calls pci_dev_put() internally. > > Direct and indirect callers of get_pci_dev() don't care for the > refcount at all unless I'm missing something. > > > > > > Also, the issue appeared in 4.16 and > > > some affected code got moved around since then: it would be problematic > > > to backport the fix to stable releases. > > > > > > All that code never cared for reference counting anyway. Call pci_dev_put() > > > from get_pci_dev() to revert to the previous behavior. > > >> Fixes: 902bdc57451c ("powerpc/powernv/idoa: Remove unnecessary pcidev > > from pci_dn") > > > Cc: stable@vger.kernel.org # v4.16 > > > Signed-off-by: Greg Kurz > > > --- > > > arch/powerpc/platforms/powernv/npu-dma.c | 15 ++++++++++++++- > > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/powerpc/platforms/powernv/npu-dma.c b/arch/powerpc/platforms/powernv/npu-dma.c > > > index e713ade30087..d8f3647e8fb2 100644 > > > --- a/arch/powerpc/platforms/powernv/npu-dma.c > > > +++ b/arch/powerpc/platforms/powernv/npu-dma.c > > > @@ -31,9 +31,22 @@ static DEFINE_SPINLOCK(npu_context_lock); > > > static struct pci_dev *get_pci_dev(struct device_node *dn) > > > { > > > struct pci_dn *pdn = PCI_DN(dn); > > > + struct pci_dev *pdev; > > > > > > - return pci_get_domain_bus_and_slot(pci_domain_nr(pdn->phb->bus), > > > + pdev = pci_get_domain_bus_and_slot(pci_domain_nr(pdn->phb->bus), > > > pdn->busno, pdn->devfn); > > > + > > > + /* > > > + * pci_get_domain_bus_and_slot() increased the reference count of > > > + * the PCI device, but callers don't need that actually as the PE > > > + * already holds a reference to the device. > > > > Imho this would be just enough. > > > > Anyway, > > > > Reviewed-by: Alexey Kardashevskiy > > > > Thanks ! > > I now realize that I forgot to add the --cc option for stable on my stgit > command line :-\. > > Cc'ing now. > > > > > How did you find it? :) > > > > While reading code to find some inspiration for OpenCAPI passthrough. :) > > I saw the following in vfio_pci_ibm_npu2_init(): > > if (!pnv_pci_get_gpu_dev(vdev->pdev)) > return -ENODEV; > > and simply followed the function calls. > > > > > > Since callers aren't > > > + * aware of the reference count change, call pci_dev_put() now to > > > + * avoid leaks. > > > + */ > > > + if (pdev) > > > + pci_dev_put(pdev); > > > + > > > + return pdev; > > > } > > > > > > /* Given a NPU device get the associated PCI device. */ > > > > > >