From: Leon Romanovsky <leon@kernel.org>
To: Alex Williamson <alex@shazbot.org>
Cc: "Matt Evans" <matt@ozlabs.org>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Alex Mastro" <amastro@fb.com>,
"Christian König" <christian.koenig@amd.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Logan Gunthorpe" <logang@deltatee.com>,
"Kevin Tian" <kevin.tian@intel.com>,
"Pranjal Shrivastava" <praan@google.com>,
"Longfang Liu" <liulongfang@huawei.com>,
"Mahmoud Adam" <mngyadam@amazon.de>,
"David Matlack" <dmatlack@google.com>,
"Björn Töpel" <bjorn@kernel.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Ankit Agrawal" <ankita@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Vivek Kasireddy" <vivek.kasireddy@intel.com>,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
kvm@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 1/9] PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release()
Date: Wed, 29 Jul 2026 13:08:40 +0300 [thread overview]
Message-ID: <20260729100840.GM12003@unreal> (raw)
In-Reply-To: <20260728163343.2a39a8d1@shazbot.org>
On Tue, Jul 28, 2026 at 04:33:43PM -0600, Alex Williamson wrote:
> Hi Leon,
>
> Please see below...
>
> On Wed, 15 Jul 2026 18:47:24 +0100
> Matt Evans <matt@ozlabs.org> wrote:
>
> > Preparing for a refactor in a subsequent patch, split the pool-related
> > release code into a new pci_p2pdma_release_pool() function.
> >
> > This allows future compile-time selection of a null implementation for
> > pci_p2pdma_release_pool(), when p2pdma.c is refactored into core- and
> > P2P-related files.
> >
> > Signed-off-by: Matt Evans <matt@ozlabs.org>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> > ---
> > drivers/pci/p2pdma.c | 24 ++++++++++++++----------
> > 1 file changed, 14 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> > index b2d5266f8653..498bca257419 100644
> > --- a/drivers/pci/p2pdma.c
> > +++ b/drivers/pci/p2pdma.c
> > @@ -226,6 +226,17 @@ static const struct dev_pagemap_ops p2pdma_pgmap_ops = {
> > .folio_free = p2pdma_folio_free,
> > };
> >
> > +static void pci_p2pdma_release_pool(struct pci_dev *pdev,
> > + struct pci_p2pdma *p2pdma)
> > +{
> > + if (!p2pdma->pool)
> > + return;
> > +
> > + synchronize_rcu();
>
> Sashiko notes[1] a high, preexisting issue here that looks like it was
> introduced via 372d6d1b8ae3 ("PCI/P2PDMA: Refactor to separate core P2P
> functionality from memory allocation"). That commit creates a two-tier
> scheme where the optional memory allocation capabilities, such as the
> pool, live above a core layer. Prior to that commit, this synchronize
> RCU call was unconditional. Making it conditional on the pool suggests
> it was only considered relevant to the optional layer.
>
> However, map_types, which remains in the core layer, is RCU referenced.
> Was the synchronize_rcu() call here miscategorized into the optional
> tier? Should it instead have remained unconditional?
I remember this concern when I wrote the patches and wanted to remove
RCU entirely. I revisited the Sashiko report, but reached the same
conclusion again.
The "bug" reported by Sashiko does not exist. The two-layer split
ensures that p2p is bound to the driver's lifecycle. As a result,
pdev->p2pdma is assigned and cleared only once during the lifetime of
pdev.
In this case, the RCU primitives are effectively NOPs, since nothing
will ever update that pointer.
I still needed to keep rcu_dereference() in
pci_p2pdma_map_type() to satisfy static analyzers, which would
otherwise complain about accessing an RCU-protected pointer without the
proper annotations.
RCU is used only in the sysfs flow.
Thanks
>
> We might need a precursor Fixes: patch to this series that makes it
> unconditional in pci_p2pdma_release(), so that it remains there with
> this refactor rather than becoming part of this new pool release
> function. Thanks,
>
> Alex
>
> [1]https://lore.kernel.org/all/20260715180521.3CDD61F00A3A@smtp.kernel.org/
>
> > + gen_pool_destroy(p2pdma->pool);
> > + sysfs_remove_group(&pdev->dev.kobj, &p2pmem_group);
> > +}
> > +
> > static void pci_p2pdma_release(void *data)
> > {
> > struct pci_dev *pdev = data;
> > @@ -237,15 +248,8 @@ static void pci_p2pdma_release(void *data)
> >
> > /* Flush and disable pci_alloc_p2p_mem() */
> > pdev->p2pdma = NULL;
> > - if (p2pdma->pool)
> > - synchronize_rcu();
> > + pci_p2pdma_release_pool(pdev, p2pdma);
> > xa_destroy(&p2pdma->map_types);
> > -
> > - if (!p2pdma->pool)
> > - return;
> > -
> > - gen_pool_destroy(p2pdma->pool);
> > - sysfs_remove_group(&pdev->dev.kobj, &p2pmem_group);
> > }
> >
> > /**
> > @@ -946,8 +950,8 @@ void *pci_alloc_p2pmem(struct pci_dev *pdev, size_t size)
> > struct pci_p2pdma *p2pdma;
> >
> > /*
> > - * Pairs with synchronize_rcu() in pci_p2pdma_release() to
> > - * ensure pdev->p2pdma is non-NULL for the duration of the
> > + * Pairs with synchronize_rcu() in pci_p2pdma_release_pool()
> > + * to ensure pdev->p2pdma is non-NULL for the duration of the
> > * read-lock.
> > */
> > rcu_read_lock();
>
next prev parent reply other threads:[~2026-07-29 10:08 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 17:47 [PATCH v5 0/9] vfio/pci: Add mmap() for DMABUFs Matt Evans
2026-07-15 17:47 ` [PATCH v5 1/9] PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() Matt Evans
2026-07-15 18:05 ` sashiko-bot
2026-07-17 8:02 ` Tian, Kevin
2026-07-28 22:33 ` Alex Williamson
2026-07-29 10:08 ` Leon Romanovsky [this message]
2026-07-30 16:45 ` Pranjal Shrivastava
2026-07-15 17:47 ` [PATCH v5 2/9] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE Matt Evans
2026-07-15 18:03 ` sashiko-bot
2026-07-17 8:02 ` Tian, Kevin
2026-07-30 19:37 ` Pranjal Shrivastava
2026-07-15 17:47 ` [PATCH v5 3/9] vfio/pci: Add a helper to look up PFNs for DMABUFs Matt Evans
2026-07-15 18:08 ` sashiko-bot
2026-07-17 8:02 ` Tian, Kevin
2026-07-29 17:52 ` Alex Williamson
2026-07-30 17:34 ` Matt Evans
2026-07-30 22:55 ` Pranjal Shrivastava
2026-07-15 17:47 ` [PATCH v5 4/9] vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA Matt Evans
2026-07-15 18:12 ` sashiko-bot
2026-07-27 13:45 ` Matt Evans
2026-07-15 17:47 ` [PATCH v5 5/9] vfio/pci: Convert BAR mmap() to use a DMABUF Matt Evans
2026-07-15 18:13 ` sashiko-bot
2026-07-27 13:45 ` Matt Evans
2026-07-15 17:47 ` [PATCH v5 6/9] vfio/pci: Provide a user-facing name for BAR mappings Matt Evans
2026-07-15 18:01 ` sashiko-bot
2026-07-17 8:03 ` Tian, Kevin
2026-07-29 17:52 ` Alex Williamson
2026-07-30 14:37 ` Matt Evans
2026-07-15 17:47 ` [PATCH v5 7/9] vfio/pci: Clean up BAR zap and revocation Matt Evans
2026-07-15 18:00 ` sashiko-bot
2026-07-17 8:03 ` Tian, Kevin
2026-07-29 17:52 ` Alex Williamson
2026-07-30 14:47 ` Matt Evans
2026-07-30 23:20 ` Pranjal Shrivastava
2026-07-15 17:47 ` [PATCH v5 8/9] vfio/pci: Support mmap() of a VFIO DMABUF Matt Evans
2026-07-15 18:17 ` sashiko-bot
2026-07-17 8:03 ` Tian, Kevin
2026-07-30 23:33 ` Pranjal Shrivastava
2026-07-15 17:47 ` [PATCH v5 9/9] vfio/pci: Permanently revoke a DMABUF on request Matt Evans
2026-07-15 18:11 ` sashiko-bot
2026-07-27 13:45 ` Matt Evans
2026-07-17 8:03 ` Tian, Kevin
2026-07-30 23:43 ` Pranjal Shrivastava
2026-07-15 18:12 ` [PATCH v5 0/9] vfio/pci: Add mmap() for DMABUFs David Matlack
2026-07-16 14:51 ` Matt Evans
2026-07-16 21:23 ` David Matlack
2026-07-17 8:42 ` David Laight
2026-07-17 16:30 ` David Matlack
2026-07-17 17:12 ` Matt Evans
2026-07-20 21:50 ` David Matlack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260729100840.GM12003@unreal \
--to=leon@kernel.org \
--cc=alex@shazbot.org \
--cc=amastro@fb.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn@kernel.org \
--cc=christian.koenig@amd.com \
--cc=dmatlack@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liulongfang@huawei.com \
--cc=logang@deltatee.com \
--cc=matt@ozlabs.org \
--cc=mngyadam@amazon.de \
--cc=praan@google.com \
--cc=sumit.semwal@linaro.org \
--cc=vivek.kasireddy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.