Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp1846778ybb; Fri, 29 Mar 2019 12:33:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqyq1ZviRAI4irhUoyFSn05G7gJ5/Dvd7jyCGER4lVs3ezshHUYC5me6dRaJ0a6m6M5ovGaB X-Received: by 2002:a63:6c43:: with SMTP id h64mr45861757pgc.22.1553888031624; Fri, 29 Mar 2019 12:33:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553888031; cv=none; d=google.com; s=arc-20160816; b=AKuVouQeIEkHcm/Hg/qJWqcvY+W3505Qe3BGDnfAFiejorDU409G0ETYx8quenctqa 3FcBfGdqlhyueIMgZYK+t6c6MViFyElqugJOo3LcuUjnaNlNAaJkaUnKaelzH6VRyVba pEQ+qYquqZVXL4wkxoFBQmhAdLqOGEdoID2u+c3QjClq7jGyCua2IzgDtAO72XWhoIGB fbozqcbh5G6Ea+IgZtBuNAN10Lbbbiyy7QD0MOE3SgihcrkOMiqwKgZyzXEIV34FC/+Q SG1ykinYteYOu2OAZIIBxrlhxsefD29Bcix1LApMEBNdklfxEnooqh/WftMvr1pE0AnX yZrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=s4Yzf+CeFFZ/OjTiJqtBkGZm16+m8nmoCemxugx67kE=; b=gbFtQD6+pyAki35t4FbC13q/tKm9O/5YQokt6CWzEYCnvPGeRt5oGSLNdiFqWup77u oKzn0N/qa5299kRuYxpwP71M4otpq8yaCt6NBd626DxLVcKyHwD1uDYPtBN4pfVIdKPl mcwpltfUpn3HPs27a0MZwBCdOzkWHdblMvxyrvV+hg07xhAJJE4fVReFBzZ/CbmQcy/F MDTrtjc1oZqTflDrGDMH7MgnA0kn60Lvv1yiUgVGNSkMp7Fv4TrA/RaPS+SsA/MHEzj3 lxEzeAhX0nRFexSy8Hr2cq2Sbc3l7cwkt4EVYQj4GXCF2tMqof0XK7T/vTBCQ9SbsAnT 9Zhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=zxZsAqHj; 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g21si2501542pgi.448.2019.03.29.12.33.35; Fri, 29 Mar 2019 12:33: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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=zxZsAqHj; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729926AbfC2Tc6 (ORCPT + 99 others); Fri, 29 Mar 2019 15:32:58 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:38459 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729652AbfC2Tc5 (ORCPT ); Fri, 29 Mar 2019 15:32:57 -0400 Received: by mail-ot1-f67.google.com with SMTP id e80so3076696ote.5 for ; Fri, 29 Mar 2019 12:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s4Yzf+CeFFZ/OjTiJqtBkGZm16+m8nmoCemxugx67kE=; b=zxZsAqHjy2Y9Bx4xA6zF2h+1CbpYruowgarysCor6ANLjnLGePYd87HqKjmFW25UWN hPmO2ck4OPgaGeQJMv8/EEEWlng/kHNbGlTXKS9B7dGBi52AxxxV7mqOV9YXV5s+J5b9 46KrNLdVwWVSeUEdKUIQw/11HOobEoq2gXKv+Ga7wH72ZXFc4MPtFwgfzMiF0D+OiWtu Se/2SEFgkY8o67XAMWtQQSHCVzrAgci4FUoJViyvTORZHdqQ5expOvSUC5Zwch0xld1d 4v7hpaOQRzUd704JnvlH6thRYy1kNEZd0zkL28FI61mqAGS3TN04F6ZYcALuPCb/a4dK qApQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s4Yzf+CeFFZ/OjTiJqtBkGZm16+m8nmoCemxugx67kE=; b=gcmvr4Jlw4LzjLMbO8q9Koi2TPycm/ivlQatnkyGsr1j1czv6TfBzABvAPJ62Cx5zr k0PdBhj294r9sX+Lxc/EAP3KfkoZll1NF4sbfbNT0g72deuDO7+PETN1GE/DHnmOuyN6 uggzADgvutVtTYeg6xukrg/WwahBgni3hPe8Tgd9fzPlBGTl77bMOfqvtgoJFnA+TkH7 /sXijsmVIj+kc9va8S6gyg2rlU19xpifYPl/z51aRujGEB1dYz+fzY08wPNE1ow274jO gCPxekEXtBXpWmKP0ZAhIdVOCXTI+MjvKwGTcDmai996CKXXifVa/swApr8rX6+IZvBM 44lQ== X-Gm-Message-State: APjAAAXbFP0BFtqeZsLawmYi5lZ2fvAMaPvmErkNn6hKh9+2enQtotIJ sRx3o3EVGnLEH+K7TTfZvx/h+9a/RH1Cb6ApLHDB7g== X-Received: by 2002:a9d:7749:: with SMTP id t9mr6559409otl.229.1553887977043; Fri, 29 Mar 2019 12:32:57 -0700 (PDT) MIME-Version: 1.0 References: <155387324370.2443841.574715745262628837.stgit@dwillia2-desk3.amr.corp.intel.com> <155387327020.2443841.6446837127378298192.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Dan Williams Date: Fri, 29 Mar 2019 12:32:44 -0700 Message-ID: Subject: Re: [PATCH 5/6] pci/p2pdma: Track pgmap references per resource, not globally To: Logan Gunthorpe Cc: Andrew Morton , Bjorn Helgaas , Christoph Hellwig , Linux MM , linux-pci@vger.kernel.org, linux-nvdimm , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 29, 2019 at 10:50 AM Logan Gunthorpe wrote: > > Thanks Dan, this is great. I think the changes in this series are > cleaner and more understandable than the patch set I had sent earlier. > > However, I found a couple minor issues with this patch: > > On 2019-03-29 9:27 a.m., Dan Williams wrote: > > static void pci_p2pdma_release(void *data) > > { > > struct pci_dev *pdev = data; > > @@ -103,12 +110,12 @@ static void pci_p2pdma_release(void *data) > > if (!pdev->p2pdma) > > return; > > > > - wait_for_completion(&pdev->p2pdma->devmap_ref_done); > > - percpu_ref_exit(&pdev->p2pdma->devmap_ref); > > + /* Flush and disable pci_alloc_p2p_mem() */ > > + pdev->p2pdma = NULL; > > + synchronize_rcu(); > > > > gen_pool_destroy(pdev->p2pdma->pool); > > I missed this on my initial review, but it became obvious when I tried > to test the series: this is a NULL dereference seeing pdev->p2pdma was > set to NULL a few lines up. Ah, yup. > When I fix this by storing p2pdma in a local variable, the patch set > works and never seems to crash when I hot remove p2pdma memory. Great! > > > void *pci_alloc_p2pmem(struct pci_dev *pdev, size_t size) > > { > > - void *ret; > > + void *ret = NULL; > > + struct percpu_ref *ref; > > > > + rcu_read_lock(); > > if (unlikely(!pdev->p2pdma)) > > - return NULL; > > Using RCU here makes sense to me, however I expect we should be using > the proper rcu_assign_pointer(), rcu_dereference() and __rcu tag with > pdev->p2pdma. If only to better document what's being protected with the > new RCU calls. I think just add a comment because those helpers are for cases where the rcu protected pointer is allowed to race the teardown. In this case we're using rcu just as a barrier to force the NULL check to resolve.