Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Leon Romanovsky" <leon@kernel.org>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 08/13] PCI/P2PDMA: Honor ACS egress control vectors
Date: Thu, 06 Aug 2026 11:47:42 +0000	[thread overview]
Message-ID: <20260806114743.8B8FB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806-fix-p2p-acs-v2-8-0cec14812965@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Cross-domain PCIe ACS Egress Control Vector evaluation uses meaningless port numbers when devices reside on different host bridges.
--

--- Patch [8]: [PATCH v2 08/13] PCI/P2PDMA: Honor ACS egress control vectors ---
commit 96de4ef43ce98491771577d7338b7224cb26b816
Author: Leon Romanovsky <leon@kernel.org>

PCI/P2PDMA: Honor ACS egress control vectors

This commit updates P2PDMA to properly evaluate the ACS Egress Control Vector
when determining routing between peers. It reads the vector where the paths
diverge below their common upstream port, treating a clear vector bit as a
direct path and a set bit (without Request Redirect) as an ACS Violation.

> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c

[ ... ]

> @@ -770,25 +770,44 @@ calc_map_type_and_dist(struct pci_dev *provider, struct pci_dev *client,
>  	 */
>  	no_common_upstream = true;
>  
> -check_b_path_acs:
> -	bb = b;
> +check_paths_acs:
> +	*dist = dist_a + dist_b;
> +	bb = provider;
>  
>  	while (bb) {
> +		target = bb == a_child ? b_child : NULL;
> +		state = pci_acs_p2pdma_state(bb, target);

[Severity: High]
When no_common_upstream is true, the provider and client reside on different
host bridges. Does this cause pci_acs_p2pdma_state() to evaluate the ACS
Egress Control Vector using a target from a completely different PCIe domain?

If bb == a_child, b_child is passed as the target. Down in
pci_acs_egress_ctrl_set(), the link capabilities of the foreign port are used
to extract a target port number:

drivers/pci/pci.c:pci_acs_egress_ctrl_set() {
    ...
    target_port = FIELD_GET(PCI_EXP_LNKCAP_PN, lnkcap);
    ...
    ret = pci_read_config_dword(pdev,
                                pdev->acs_cap + PCI_ACS_EGRESS_CTL_V +
                                (target_port / 32) * sizeof(vector),
                                &vector);
    ...
}

Since pdev and target are on different host bridges, does this use a
meaningless port number as an index? If so, this could read arbitrary bits
from the hardware configuration space and potentially result in incorrect ACS
routing decisions or spurious violation warnings.

> +		if (state != PCI_ACS_P2PDMA_DIRECT) {
> +			seq_buf_print_bus_devfn(&acs_list, bb);
> +			if (state == PCI_ACS_P2PDMA_REDIRECT)
> +				acs_redirect_cnt++;
> +			else if (!acs_unsupported)
> +				acs_unsupported = bb;
> +		}
> +
>  		if (a == bb)
>  			break;
>  
> -		if (pci_acs_p2pdma_state(bb, NULL) ==
> -		    PCI_ACS_P2PDMA_REDIRECT) {
> -			seq_buf_print_bus_devfn(&acs_list, bb);
> -			acs_cnt++;
> -		}
> -
>  		bb = pci_upstream_bridge(bb);
>  	}
>  
> -	*dist = dist_a + dist_b;
> -
> -	if (!acs_cnt) {
> +	bb = client;
> +
> +	while (bb && a != bb) {
> +		target = bb == b_child ? a_child : NULL;
> +		state = pci_acs_p2pdma_state(bb, target);

[Severity: High]
Similarly here, if the devices are on different host bridges, a_child and
b_child are on different domains. Does passing a_child as the target to
b_child's ACS evaluation create the same cross-domain hardware configuration
read issue?

> +		if (state != PCI_ACS_P2PDMA_DIRECT) {
>  			seq_buf_print_bus_devfn(&acs_list, bb);
> -			acs_cnt++;
> +			if (state == PCI_ACS_P2PDMA_REDIRECT)
> +				acs_redirect_cnt++;
> +			else if (!acs_unsupported)
> +				acs_unsupported = bb;
>  		}
>  
>  		bb = pci_upstream_bridge(bb);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com?part=8

  reply	other threads:[~2026-08-06 11:47 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 [this message]
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
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=20260806114743.8B8FB1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=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