All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 6/7] PCI: Fix composite resource sizing
Date: Fri, 02 Oct 2026 11:51:12 +0000	[thread overview]
Message-ID: <20261002115113.0FC091F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261002113319.6652-7-ilpo.jarvinen@linux.intel.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] pci: undersized bridge windows during hotplug due to ignored optional resources
- [High] pci: gap calculation ignores expanded sizes, undersizing optional bridge windows
- [High] pci: gap optimization incorrectly assumes perfect packing, causing allocation failures
--

commit 17592808ea429ea63c8337b7e33d67bb459cf0c2
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Subject: PCI: Fix composite resource sizing

This commit adds a bridge window gap size calculator to correctly pad
alignments for non-aligning composite resources back to back. The gap is
calculated based on the minimal alignment for the bridge window.

Link: https://lore.kernel.org/linux-pci/20260903063124.9316-1-nbritton@exabit.io/

> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 7ca0e9f4ffb63..9d828a59bd002 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
[ ... ]
> +static resource_size_t calculate_win_gap_size(struct pci_bus *bus,
> +					      struct resource *b_res,
> +					      resource_size_t win_align,
> +					      bool optional)
> +{
> +	resource_size_t safe_gap = 0, remainders = 0;
> +	unsigned int nonaligning = 0;
> +	struct pci_dev *dev;
> +
> +	list_for_each_entry(dev, &bus->devices, bus_list) {
> +		struct resource *r;
> +		int i;
> +
> +		pci_dev_for_each_resource(dev, r, i) {
> +			resource_size_t r_size, remainder, aligning;
> +
> +			if (!pdev_resources_assignable(dev) ||
> +			    !pdev_resource_should_fit(dev, r))
> +				continue;
> +			if (b_res != pbus_select_window(bus, r))
> +				continue;
> +
> +			if (!optional && pci_resource_is_optional(dev, i))
> +				continue;
> +
> +			r_size = resource_size(r);

[Severity: High]
During the optional sizing pass, calculate_win_gap_size() is called with
optional=true, but the gap requirement is evaluated using the unexpanded base
size from resource_size(r). It does not appear to consider the requested
add_size expansions from realloc_head.

If a child bridge's base size perfectly aligns to the parent's add_align
(resulting in a 0 gap here), but the child's expanded size is unaligned, won't
this result in an undersized parent optional window because it failed to
provision the padding gap for the expanded size?

> +			if (r_size <= win_align)
> +				continue;
> +
> +			aligning = ALIGN_DOWN(r_size, win_align);
> +			remainder = r_size - aligning;
> +			if (!remainder)
> +				continue;
> +
> +			nonaligning++;
> +			remainders += remainder;
> +			safe_gap += win_align - remainder;
> +		}
> +	}
> +
> +	if (nonaligning == 2 && (remainders <= win_align))
> +		return win_align - remainders;

[Severity: High]
Does this optimization assume perfect packing of fragmented remainders,
violating the strict alignment constraints of the resources themselves?

If both resources require win_align alignment (e.g., both have size 5MB and
alignment 4MB), the second resource cannot be placed adjacent to the first
and must be bumped to the next 4MB boundary. Wouldn't this reduction in the
gap cause the second resource to fail assignment because the bridge window
is undersized?

> +
> +	if (nonaligning >= 2)
> +		return safe_gap;
> +
> +	return 0;
> +}
[ ... ]
> @@ -1345,7 +1416,8 @@ static void pbus_size_mem(struct pci_bus *bus, struct resource *b_res,
>  	win_align = pci_min_window_alignment(bus, b_res->flags);
>  	min_align = calculate_head_align(aligns, max_order);
>  	min_align = max(min_align, win_align);
> -	size0 = calculate_memsize(size, realloc_head ? 0 : add_size,
> +	gap_size = calculate_win_gap_size(bus, b_res, min_align, false);

[Severity: High]
When a device with optional resources (like SR-IOV BARs) is sized via a path
where realloc_head is NULL (e.g., during hotplug via pci_bus_size_bridges()),
pbus_size_mem() accumulates the sizes of those optional resources into the
base size because pbus_size_mem_optional() returns false.

However, the gap calculator is invoked here with optional=false, which
unconditionally drops optional resources. Doesn't this cause their required
alignment padding gaps to be omitted from the bridge window entirely, leaving
the bridge window undersized?

> +	size0 = calculate_memsize(size + gap_size, realloc_head ? 0 : add_size,
>  				  0, win_align);
>  
>  	if (size0) {
> @@ -1355,8 +1427,9 @@ static void pbus_size_mem(struct pci_bus *bus, struct resource *b_res,
>  
>  	if (realloc_head && (add_size > 0 || children_add_size > 0)) {
>  		add_align = max(min_align, add_align);
> -		size1 = calculate_memsize(size, add_size, children_add_size,
> -					  win_align);
> +		gap_size = calculate_win_gap_size(bus, b_res, add_align, true);
> +		size1 = calculate_memsize(size + gap_size, add_size,
> +					  children_add_size, win_align);
>  	}
>  
>  	if (!size0 && !size1) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002113319.6652-1-ilpo.jarvinen@linux.intel.com?part=6

  reply	other threads:[~2026-10-02 11:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 11:33 [PATCH v2 0/7] PCI: Resource placement algorithm fixes Ilpo Järvinen
2026-10-02 11:33 ` [PATCH v2 1/7] resource: Mark free space assigned Ilpo Järvinen
2026-10-02 11:43   ` sashiko-bot
2026-10-02 11:33 ` [PATCH v2 2/7] PCI/parisc: Clean up resource debug print & use dynamic debug Ilpo Järvinen
2026-10-02 11:43   ` sashiko-bot
2026-10-02 11:33 ` [PATCH v2 3/7] PCI: Honor alignment overrides Ilpo Järvinen
2026-10-02 11:46   ` Jani Nikula
2026-10-02 11:49   ` sashiko-bot
2026-10-02 11:33 ` [PATCH v2 4/7] PCI: Fix nesting windows with remainder at the left edge Ilpo Järvinen
2026-10-02 11:42   ` sashiko-bot
2026-10-02 11:33 ` [PATCH v2 5/7] PCI: Place resources to either edge of the window Ilpo Järvinen
2026-10-02 11:46   ` sashiko-bot
2026-10-02 11:33 ` [PATCH v2 6/7] PCI: Fix composite resource sizing Ilpo Järvinen
2026-10-02 11:51   ` sashiko-bot [this message]
2026-10-02 11:33 ` [PATCH v2 7/7] PCI/quirks: Avoid certain address on Genoa systems Ilpo Järvinen
2026-10-02 11:48   ` sashiko-bot
2026-10-02 13:47     ` Ilpo Järvinen
2026-10-02 13:12   ` Mario Limonciello
2026-10-04 15:44   ` Borislav Petkov
2026-10-09 12:01     ` Ilpo Järvinen
2026-10-05 18:47   ` Bjorn Helgaas
2026-10-06 12:02     ` Ilpo Järvinen

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=20261002115113.0FC091F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --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 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.