Re: [PATCH 5/5] PCI/quirks: Avoid certain BAR 0 address with igb

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] pci: skipping hardware update in bar0_address_breakage() causes desync
- [High] pci: ignoring pci_release_resource() return corrupts tree
--

commit 140645b0838c61616e4734fb4c852db528a2c054
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Wed Sep 23 13:17:55 2026 +0000

    PCI/quirks: Avoid certain BAR 0 address with igb
    
This patch adds a quirk to reshuffle igb resources when BAR 0 is placed at 
0x9c000000, which previously caused the driver to fail during probe due to 
unexpected reads. The quirk uses BAR 3 to block the problematic address by 
relocating it.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index de9bbccda21fd..e6f3e2ab1fd4e 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
[ ... ]
> @@ -6288,6 +6288,62 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1536, rom_bar_overlap_defect);
[ ... ]
> +static void bar0_address_breakage(struct pci_dev *dev)
> +{
[ ... ]
> +	pci_dev_for_each_resource(dev, res, i) {
> +		if (!resource_assigned(res) ||
> +		    resource_type(res) != IORESOURCE_MEM)
> +			continue;
> +
> +		pci_release_resource(dev, i);

[Severity: High]
Can ignoring the return value of pci_release_resource() cause tree
corruption?

If a resource fails to release (e.g., returning -EBUSY), it remains actively
linked in the system's resource sibling tree. The code below then modifies
its boundaries unconditionally via resource_set_range().

Does modifying the start and end bounds of a node while it is still linked
violate the strict address-ordered sibling list invariants of the resource
tree, and cause pci_claim_resource() to corrupt pointers by re-inserting it?

> +	}
> +
> +	resource_set_range(bar3, broken_addr, resource_size(bar3));
> +	bar3->flags &= ~IORESOURCE_UNSET;
> +	pci_claim_resource(dev, 3);
> +	if (!resource_assigned(bar3)) {
> +		bar3->flags |= IORESOURCE_UNSET;
> +		pci_warn(dev, "resource relocation failed\n");
> +	}
> +
> +	pci_dev_for_each_resource(dev, res, i) {
> +		if (resource_assigned(res) ||
> +		    resource_type(res) != IORESOURCE_MEM)
> +			continue;
> +
> +		ret = pci_assign_resource(dev, i);

[Severity: High]
Does skipping BAR 3 in this loop cause a desync between the software
resource tree and the physical hardware?

Since pci_claim_resource() updates the software resource tree but does not
write to the physical hardware PCI configuration registers, the hardware BAR
needs to be updated.

However, because BAR 3 was claimed and marked assigned in software earlier,
the resource_assigned() check skips it here. This permanently bypasses the
hardware register update. 

Would this leave the OS thinking BAR 3 is at 0x9c000000 while the physical
hardware remains at its old address, causing the MSI-X table reads to fail
and creating a possible PCIe bus conflict?

> +		if (ret)
> +			pci_warn(dev, "resource relocation failed\n");
> +	}
> +}

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