From: Leon Romanovsky <leon@kernel.org>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Chaitanya Kulkarni <kch@nvidia.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jens Axboe <axboe@kernel.dk>, Alex Williamson <alex@shazbot.org>,
Ankit Agrawal <ankita@nvidia.com>, Jason Gunthorpe <jgg@ziepe.ca>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
"Joerg Roedel (AMD)" <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, iommu@lists.linux.dev,
Tushar Dave <tdave@nvidia.com>, Matt Evans <matt@ozlabs.org>
Subject: Re: I
Date: Sun, 30 Aug 2026 12:14:56 +0300 [thread overview]
Message-ID: <20260830091456.GD24140@unreal> (raw)
In-Reply-To: <d559d41c-5cba-4a95-bc8b-b1f78a49a18c@deltatee.com>
On Mon, Aug 24, 2026 at 02:29:34PM -0600, Logan Gunthorpe wrote:
>
>
> On 2026-08-21 13:38, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > pdev->p2pdma has two lifetime models. Provider-based entry points are
> > quiesced by their driver before remove completes. pci_p2pmem_find_many()
> > and the p2pmem sysfs attributes can race with unbind and therefore rely
> > on the teardown grace period.
> >
> > Document publication, teardown, and how the grace period protects both
> > the struct pci_p2pdma object and its optional gen_pool.
> >
> > Tested-by: Tushar Dave <tdave@nvidia.com>
> > Cc: Alex Williamson <alex@shazbot.org>
> > Cc: Matt Evans <matt@ozlabs.org>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > drivers/pci/p2pdma.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 53 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> > index a77ef9deb3c6..49bc8cf06240 100644
> > --- a/drivers/pci/p2pdma.c
> > +++ b/drivers/pci/p2pdma.c
> > @@ -21,6 +21,39 @@
> > #include <linux/seq_buf.h>
> > #include <linux/xarray.h>
> >
> > +/*
> > + * Lifetime and RCU usage
> > + *
> > + * Within one driver bind, pdev->p2pdma is published exactly once, by
>
> Is published the right verb here? Seems like we use published for
> different purposes in p2pdma and calling pcim_p2pdma_init() publishing
> reads strangely.
It should probably say "pdev->p2pdma is set exactly once".
>
> > + * pcim_p2pdma_init(), and cleared exactly once, by the pci_p2pdma_release()
> > + * devres action that the same function installs. It is never re-pointed at a
>
> "It is never re-pointed at" is some strange wording. I had to read it a
> few times to understand what it is saying.
Sorry about that. AI + non-english speaker = "re-pointed".
>
> > + * second struct pci_p2pdma, so a reader that observes a non-NULL pointer
> > + * always observes the same, fully initialised object. That object is devres
> > + * memory allocated before the action is installed, so devres frees it only
> > + * after pci_p2pdma_release() has returned.
>
> I don't quite follow the point of this paragraph. It's like it's
> building to some kind of gotcha, but all it seems to be saying is is the
> life cycle of pdev->p2pdma is the same as the lifecycle of pdev.
Yes
>
> > + * Most exported entry points reach pdev->p2pdma through a struct pci_dev or a
> > + * struct p2pdma_provider owned by the provider driver, and
> > + * pcim_p2pdma_provider() requires callers to drop those references before the
> > + * driver's remove() completes. Those cannot run concurrently with
> > + * pci_p2pdma_release(), and their rcu_dereference() calls are simply how an
> > + * __rcu pointer is read.
> > + *
> > + * pci_p2pmem_find_many() and the p2pmem sysfs attributes are the exceptions.
> > + * The first walks every PCI device, so it can reach a provider whose driver is
> > + * unbinding: pci_get_device() pins the struct pci_dev, not the driver. The
> > + * second is reachable from userspace until sysfs_remove_group() runs at the end
> > + * of the release. pci_has_p2pmem() must dereference the object to determine
> > + * whether it owns a gen_pool, so even a poolless object must remain alive until
>
> Maybe a hyphen with pool-less or maybe better to use plain language: "so
> even a device without a pool must remain alive..."
I will try to simplify the language.
>
> > + * that RCU reader exits. The sysfs group is created with the pool.
> > + *
> > + * The grace period in pci_p2pdma_release() first protects the struct
> > + * pci_p2pdma itself from being freed while pci_has_p2pmem() is using it. For a
> > + * pool-backed provider it also fences the gen_pool: gen_pool_alloc_owner()
> > + * walks pool->chunks under RCU and gen_pool_destroy() frees those chunks
> > + * without waiting for a grace period of its own, so pci_alloc_p2pmem() and
> > + * p2pmem_alloc_mmap() hold rcu_read_lock() across the allocation.
> > + */
> > struct pci_p2pdma {
> > struct gen_pool *pool;
> > bool p2pmem_published;
> > @@ -235,9 +268,19 @@ static void pci_p2pdma_release(void *data)
> > if (!p2pdma)
> > return;
> >
> > - /* Flush and disable pci_alloc_p2p_mem() */
> > + /*
> > + * Stop new RCU readers and wait for readers that observed p2pdma before
> > + * allowing devres to free it. This is required even without a pool,
> > + * because pci_has_p2pmem() dereferences every non-NULL p2pdma it finds.
> > + * For a pool-backed provider this also fences gen_pool_destroy().
> > + */
> > RCU_INIT_POINTER(pdev->p2pdma, NULL);
> > synchronize_rcu();
> > +
> > + /*
> > + * The grace period also ensures no RCU reader can still be accessing
> > + * map_types here.
> > + */
> > xa_destroy(&p2pdma->map_types);
> >
> > if (!p2pdma->pool)
> > @@ -255,6 +298,9 @@ static void pci_p2pdma_release(void *data)
> > * for a PCI device. It allocates and sets up the necessary data
> > * structures to support P2PDMA operations, including mapping type
> > * tracking.
> > + *
> > + * The state is published once per driver bind and torn down by a devres
>
> I still find the use of "published" here a bit odd and I'm not sure what
> "state" it is referring to.
published == assigned.
>
> > + * action on unbind. Repeated calls for the same device are a no-op.
> > */
> > int pcim_p2pdma_init(struct pci_dev *pdev)
> > {
> > @@ -786,6 +832,12 @@ calc_map_type_and_dist(struct pci_dev *provider, struct pci_dev *client,
> > map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;
> > }
> > done:
> > + /*
> > + * pci_p2pmem_find_many() reaches this with a provider whose driver may
> > + * be unbinding, so the store runs under RCU: pci_p2pdma_release()
> > + * clears the pointer and waits for readers before destroying
> > + * map_types. See "Lifetime and RCU usage" above.
> > + */
>
> I don't know, but this seems like we're just describing basic RCU usage
> here. I'm not sure I personally find much value in the comment.
It was mainly intended to help AI review P2P patches according to the
lifetime model.
>
> > rcu_read_lock();
> > p2pdma = rcu_dereference(provider->p2pdma);
> > if (p2pdma)
> >
>
> Thanks,
>
> Logan
next prev parent reply other threads:[~2026-08-30 9:15 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 19:38 [PATCH v4 00/18] PCI/P2PDMA: Fix ACS egress control handling Leon Romanovsky
2026-08-21 19:38 ` [PATCH v4 01/18] PCI/P2PDMA: Do not tear down the allocate attribute on registration failure Leon Romanovsky
2026-08-21 19:53 ` sashiko-bot
2026-08-21 23:08 ` Logan Gunthorpe
2026-08-24 23:22 ` Jason Gunthorpe
2026-08-21 19:38 ` [PATCH v4 02/18] PCI/P2PDMA: Wait for RCU readers before freeing state Leon Romanovsky
2026-08-21 19:48 ` sashiko-bot
2026-08-21 23:10 ` Logan Gunthorpe
2026-08-24 23:22 ` Jason Gunthorpe
2026-08-21 19:38 ` [PATCH v4 03/18] PCI/P2PDMA: Restrict the p2pmem search to pool backed providers Leon Romanovsky
2026-08-21 19:59 ` sashiko-bot
2026-08-21 23:14 ` Logan Gunthorpe
2026-08-24 23:22 ` Jason Gunthorpe
2026-08-21 19:38 ` [PATCH v4 04/18] PCI/P2PDMA: Safely terminate ACS redirect lists Leon Romanovsky
2026-08-21 19:47 ` sashiko-bot
2026-08-24 23:22 ` Jason Gunthorpe
2026-08-21 19:38 ` [PATCH v4 05/18] PCI/P2PDMA: Document the pdev->p2pdma lifetime and RCU rules Leon Romanovsky
2026-08-21 19:56 ` sashiko-bot
2026-08-24 20:29 ` I Logan Gunthorpe
2026-08-30 9:14 ` Leon Romanovsky [this message]
2026-08-21 19:38 ` [PATCH v4 06/18] PCI/P2PDMA: Gate the host bridge whitelist warning on verbose Leon Romanovsky
2026-08-21 19:47 ` sashiko-bot
2026-08-24 21:08 ` Logan Gunthorpe
2026-08-24 23:22 ` Jason Gunthorpe
2026-08-21 19:38 ` [PATCH v4 07/18] PCI/P2PDMA: Document the Address Type assumption Leon Romanovsky
2026-08-21 19:43 ` sashiko-bot
2026-08-24 23:22 ` Jason Gunthorpe
2026-08-21 19:38 ` [PATCH v4 08/18] PCI: Account for Direct Translated P2P in ACS isolation checks Leon Romanovsky
2026-08-21 19:54 ` sashiko-bot
2026-08-24 23:22 ` Jason Gunthorpe
2026-08-25 15:59 ` Logan Gunthorpe
2026-08-21 19:38 ` [PATCH v4 09/18] PCI: Add ACS egress control vector accessor Leon Romanovsky
2026-08-21 19:50 ` sashiko-bot
2026-08-21 19:38 ` [PATCH v4 10/18] PCI: Account for ACS egress control in isolation checks Leon Romanovsky
2026-08-21 19:51 ` sashiko-bot
2026-08-24 23:22 ` Jason Gunthorpe
2026-08-30 9:20 ` Leon Romanovsky
2026-08-31 12:02 ` Jason Gunthorpe
2026-08-21 19:38 ` [PATCH v4 11/18] PCI/P2PDMA: Derive peer-to-peer routing from ACS control bits Leon Romanovsky
2026-08-21 19:54 ` sashiko-bot
2026-08-22 13:31 ` Leon Romanovsky
2026-08-25 19:17 ` Logan Gunthorpe
2026-08-21 19:38 ` [PATCH v4 12/18] PCI/P2PDMA: Honor ACS egress control vectors Leon Romanovsky
2026-08-21 19:56 ` sashiko-bot
2026-08-25 19:25 ` Logan Gunthorpe
2026-08-21 19:38 ` [PATCH v4 13/18] PCI/P2PDMA: Document ACS egress control handling Leon Romanovsky
2026-08-21 19:44 ` sashiko-bot
2026-08-25 19:52 ` Logan Gunthorpe
2026-08-21 19:38 ` [PATCH v4 14/18] PCI/P2PDMA: Extract pure ACS routing decision helpers Leon Romanovsky
2026-08-21 19:49 ` sashiko-bot
2026-08-25 19:55 ` Logan Gunthorpe
2026-08-21 19:38 ` [PATCH v4 15/18] PCI/P2PDMA: Add KUnit tests for ACS routing decisions Leon Romanovsky
2026-08-21 19:50 ` sashiko-bot
2026-08-21 19:38 ` [PATCH v4 16/18] PCI/P2PDMA: Add KUnit coverage for the ACS P2P routing walk Leon Romanovsky
2026-08-21 19:51 ` sashiko-bot
2026-08-21 19:38 ` [PATCH v4 17/18] PCI: Add KUnit coverage for ACS isolation checks Leon Romanovsky
2026-08-21 19:52 ` sashiko-bot
2026-08-21 19:38 ` [PATCH v4 18/18] PCI/P2PDMA: Log detailed ACS routing diagnostics Leon Romanovsky
2026-08-21 20:02 ` sashiko-bot
2026-08-22 13:28 ` Leon Romanovsky
2026-08-25 20:02 ` Logan Gunthorpe
2026-08-30 8:37 ` Leon Romanovsky
2026-08-24 23:22 ` [PATCH v4 00/18] PCI/P2PDMA: Fix ACS egress control handling Jason Gunthorpe
2026-08-30 9:02 ` Leon Romanovsky
2026-08-31 12:00 ` Jason Gunthorpe
-- strict thread matches above, loose matches on Subject: below --
2007-04-08 5:22 I Clem P. Latham
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=20260830091456.GD24140@unreal \
--to=leon@kernel.org \
--cc=alex@shazbot.org \
--cc=ankita@nvidia.com \
--cc=axboe@kernel.dk \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kch@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=matt@ozlabs.org \
--cc=robin.murphy@arm.com \
--cc=skhan@linuxfoundation.org \
--cc=tdave@nvidia.com \
--cc=will@kernel.org \
/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.