From: Leon Romanovsky <leon@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 12/13] PCI/P2PDMA: Add KUnit coverage for the ACS P2P routing walk
Date: Fri, 7 Aug 2026 16:02:30 +0300 [thread overview]
Message-ID: <20260807130230.GA387018@unreal> (raw)
In-Reply-To: <20260806114433.D9FA81F000E9@smtp.kernel.org>
On Thu, Aug 06, 2026 at 11:44:32AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] pci_p2pdma_release() skips synchronize_rcu() when p2pdma->pool is NULL, leading to a Use-After-Free of the pci_p2pdma struct and its XArray inside RCU read-side critical sections.
> --
>
> --- Patch [12]: [PATCH v2 12/13] PCI/P2PDMA: Add KUnit coverage for the ACS P2P routing walk ---
> commit c4a68b62f4ec894cc35240eda46bf42dc5f562d9
> Author: Leon Romanovsky <leon@kernel.org>
>
> PCI/P2PDMA: Add KUnit coverage for the ACS P2P routing walk
>
> Extend the ACS KUnit suite with end-to-end coverage of
> calc_map_type_and_dist(), the provider-to-client hierarchy walk.
>
> > diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> > index c7680964d8a64..18e5339bc49e9 100644
> > --- a/drivers/pci/p2pdma.c
> > +++ b/drivers/pci/p2pdma.c
> [ ... ]
> > @@ -859,6 +859,7 @@ calc_map_type_and_dist(struct pci_dev *provider, struct pci_dev *client,
> > rcu_read_unlock();
> > return map_type;
> > }
> > +EXPORT_SYMBOL_IF_KUNIT(calc_map_type_and_dist);
>
> [Severity: High]
> This is a pre-existing issue, but does this code have a race condition
> leading to a use-after-free when interacting with pci_p2pdma_release()?
>
> If a device acts as a P2PDMA provider without setting up an allocator pool
> (for example, via vfio-pci or mlx5), pci_p2pdma_release() skips
> synchronize_rcu() because p2pdma->pool is NULL:
>
> drivers/pci/p2pdma.c:pci_p2pdma_release() {
> ...
> if (p2pdma->pool)
> synchronize_rcu();
> ...
> }
>
> When the provider driver is unbound, devres frees the pci_p2pdma structure
> and destroys the XArray. Concurrently, calc_map_type_and_dist() executing
> here inside its RCU read-side critical section can dereference the freed
> p2pdma pointer and call xa_store() on the destroyed XArray.
>
> Should synchronize_rcu() be called during release regardless of whether
> the allocator pool is set up?
No, we already discussed that here.
https://lore.kernel.org/kvm/20260729100840.GM12003@unreal/
https://lore.kernel.org/kvm/20260805003127.GJ27883@nvidia.com/
But let's see if I can write a documentation patch that helps AI
tools stop complaining.
Thanks
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com?part=12
>
next prev parent reply other threads:[~2026-08-07 13:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 11:24 [PATCH v2 00/13] PCI/P2PDMA: Fix ACS egress control handling Leon Romanovsky
2026-08-06 11:24 ` [PATCH v2 01/13] PCI/P2PDMA: Safely terminate ACS redirect lists Leon Romanovsky
2026-08-06 11:32 ` sashiko-bot
2026-08-06 11:24 ` [PATCH v2 02/13] PCI/P2PDMA: Report ACS ports when the paths share no upstream bridge Leon Romanovsky
2026-08-06 11:37 ` sashiko-bot
2026-08-07 14:35 ` Leon Romanovsky
2026-08-06 11:24 ` [PATCH v2 03/13] PCI/P2PDMA: Document the Address Type assumption Leon Romanovsky
2026-08-06 11:28 ` sashiko-bot
2026-08-06 11:24 ` [PATCH v2 04/13] PCI: Account for Direct Translated P2P in ACS isolation checks Leon Romanovsky
2026-08-06 11:35 ` sashiko-bot
2026-08-06 11:24 ` [PATCH v2 05/13] PCI: Add ACS egress control vector accessor Leon Romanovsky
2026-08-06 11:39 ` sashiko-bot
2026-08-06 11:24 ` [PATCH v2 06/13] PCI: Account for ACS egress control in isolation checks Leon Romanovsky
2026-08-06 11:40 ` sashiko-bot
2026-08-07 16:07 ` Leon Romanovsky
2026-08-06 11:24 ` [PATCH v2 07/13] PCI/P2PDMA: Derive peer-to-peer routing from ACS control bits Leon Romanovsky
2026-08-06 11:33 ` sashiko-bot
2026-08-06 11:24 ` [PATCH v2 08/13] PCI/P2PDMA: Honor ACS egress control vectors Leon Romanovsky
2026-08-06 11:47 ` sashiko-bot
2026-08-06 11:24 ` [PATCH v2 09/13] PCI/P2PDMA: Document ACS egress control handling Leon Romanovsky
2026-08-06 11:29 ` sashiko-bot
2026-08-06 11:24 ` [PATCH v2 10/13] PCI/P2PDMA: Extract pure ACS routing decision helpers Leon Romanovsky
2026-08-06 11:34 ` sashiko-bot
2026-08-06 11:24 ` [PATCH v2 11/13] PCI/P2PDMA: Add KUnit tests for ACS routing decisions Leon Romanovsky
2026-08-06 11:34 ` sashiko-bot
2026-08-06 11:24 ` [PATCH v2 12/13] PCI/P2PDMA: Add KUnit coverage for the ACS P2P routing walk Leon Romanovsky
2026-08-06 11:44 ` sashiko-bot
2026-08-07 13:02 ` Leon Romanovsky [this message]
2026-08-06 11:24 ` [PATCH v2 13/13] PCI: Add KUnit coverage for ACS isolation checks Leon Romanovsky
2026-08-06 11:37 ` sashiko-bot
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=20260807130230.GA387018@unreal \
--to=leon@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox