From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Sizhe Liu <liusizhe5@huawei.com>,
bhelgaas@google.com, jonathan.cameron@huawei.com,
shiju.jose@huawei.com, linux-pci@vger.kernel.org,
linuxarm@huawei.com, prime.zeng@hisilicon.com,
fanghao11@huawei.com, shenyang39@huawei.com
Subject: Re: [PATCH] PCI: Fix PCI bridge resource allocation when base exceeds limit
Date: Fri, 6 Feb 2026 16:17:29 -0600 [thread overview]
Message-ID: <20260206221729.GA97748@bhelgaas> (raw)
In-Reply-To: <4d9228d6-a230-6ddf-e300-fbf42d523863@linux.intel.com>
On Tue, Feb 03, 2026 at 07:21:38PM +0200, Ilpo Järvinen wrote:
> On Tue, 3 Feb 2026, Ilpo Järvinen wrote:
>
> > On Tue, 3 Feb 2026, Sizhe Liu wrote:
> >
> > > In pci_read_bridge_mmio_pref(), pci_read_bridge_mmio() and pci_read_bridge_io(),
> > > when the MEMORY_BASE value is greater than MEMORY_LIMIT,
> > > resource_set_range(res, 0, 0) is called to set both the start address
> > > and the size of the address of the PCI bridge resource to 0.
> > > However, the end address is later calculated as:
> > > res->end = res->start + size - 1
> > > As a result, the resource range becomes [0x00000000-0xffffffffffffffff]
> > > instead of the expected [0x00000000-0x00000000].
> >
> > Hi,
> >
> > Thanks for the patch but your understanding on how resources addresses
> > work is not correct.
> >
> > A zero sized resource should have end at start - 1, just like
> > resource_set_range() sets it!
> >
> > > This causes an exception in the subsequent resource claiming process,
> > > because the address range [0x00000000-0xffffffffffffffff] exceeds
> > > the range specified in the DSDT. The abnormal bridge triggers clipping
> > > when claiming resources, then the entire parent PCI bus address range
> > > becomes occupied. Other bridges on the same bus will report
> > > address conflicts during their claim process. The resource allocation
> > > may be degraded from 64-bit to 32-bit, or even worse, it fails.
> > >
> > > The related boot log is as follows:
> > > pci 0000:20:00.0: PCI bridge to [bus 21]
> > > pci 0000:20:00.0: bridge window [io size 0x0000 disabled]: can't claim; no address assigned
> > > pci 0000:20:00.0: [io 0x0000-0xffffffffffffffff disabled] clipped to [io 0x0000-0xffff disabled]
> >
> > pci_bus_clip_resource() should not touch IORESOURCE_DISABLED resources
> > nor zero sized resources. The problem seems to originate from
> > pci_claim_bridge_resources() and pci_claim_bridge_resource() which try to
> > claim such resources no matter what.
> >
> > I think pci_claim_bridge_resources() should check if IORESOURCE_DISABLED
> > is set and use continue, it already has check !r->flags which probably
> > worked prior to 8278c6914306 ("PCI: Preserve bridge window resource type
> > flags") but is no longer enough to decided if bridge window is valid or
> > not.
> >
> > Do you want to do that patch and test it? (I'm quite busy this week
> > myself.)
>
> I managed to get the patch done:
>
> --
> From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
> Date: Tue, 3 Feb 2026 19:14:30 +0200
> Subject: [PATCH 1/1] PCI: Don't claim disabled bridge windows
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The commit 8278c6914306 ("PCI: Preserve bridge window resource type
> flags") change bridge window resource behavior such that flags are no
> longer zero if the bridge window is not valid or is disabled (mainly
> to preserve the type flags for later use). If a bridge window has its
> limit smaller than base address, pci_read_bridge_*() sets both
> IORESOURCE_UNSET and IORESOURCE_DISABLED to indicate the bridge window
> exists but is not valid with the current base and limit configuration.
>
> The code in pci_claim_bridge_resources() still depends on the old
> behavior be checking validity of the bridge window solely based on
> !r->flags, whereas after the commit 8278c6914306 ("PCI: Preserve bridge
> window resource type flags"), also IORESOURCE_DISABLED may indicate
> bridge window addresses are not valid.
>
> While pci_claim_resource() does check IORESOURCE_UNSET,
> pci_claim_bridge_resource() does attempt to clip the resource if
> pci_claim_resource() fails which is not correct for not valid bridge
> window resource. As pci_bus_clip_resource() performs clipping
> regardless flags and then clears IORESOURCE_UNSET, it should not be
> called for not valid resources.
>
> The problem is visible in this log:
>
> pci 0000:20:00.0: PCI bridge to [bus 21]
> pci 0000:20:00.0: bridge window [io size 0x0000 disabled]: can't claim; no address assigned
> pci 0000:20:00.0: [io 0x0000-0xffffffffffffffff disabled] clipped to [io 0x0000-0xffff disabled]
>
> Add IORESOURCE_DISABLED check into pci_claim_bridge_resources() to
> only claim bridge windows that appear to have a valid configuration.
>
> Reported-by: Sizhe Liu <liusizhe5@huawei.com>
> Fixes: 8278c6914306 ("PCI: Preserve bridge window resource type flags")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Applied to pci/resource for v6.20, thanks!
FWIW, when applied to this message, b4 extracts Sizhe's original
patch, which isn't what we want in this case:
$ b4 am -om/ https://lore.kernel.org/all/4d9228d6-a230-6ddf-e300-fbf42d523863@linux.intel.com
...
$ head m/20260203_liusizhe5_pci_fix_pci_bridge_resource_allocation_when_base_exceeds_limit.mbx
From git@z Thu Jan 1 00:00:00 1970
Subject: [PATCH] PCI: Fix PCI bridge resource allocation when base exceeds
limit
From: Sizhe Liu <liusizhe5@huawei.com>
Date: Tue, 03 Feb 2026 10:35:45 +0800
...
> ---
> drivers/pci/setup-bus.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 6e90f46f52af..43ea635e1ea8 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -1733,6 +1733,8 @@ static void pci_claim_bridge_resources(struct pci_dev *dev)
>
> if (!r->flags || r->parent)
> continue;
> + if (r->flags & IORESOURCE_DISABLED)
> + continue;
>
> pci_claim_bridge_resource(dev, i);
> }
>
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> --
> 2.39.5
next prev parent reply other threads:[~2026-02-06 22:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 2:35 [PATCH] PCI: Fix PCI bridge resource allocation when base exceeds limit Sizhe Liu
2026-02-03 15:14 ` Ilpo Järvinen
2026-02-03 17:21 ` Ilpo Järvinen
2026-02-04 8:56 ` Sizhe LIU
2026-02-06 22:17 ` Bjorn Helgaas [this message]
2026-02-04 3:58 ` Sizhe LIU
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=20260206221729.GA97748@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=fanghao11@huawei.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liusizhe5@huawei.com \
--cc=prime.zeng@hisilicon.com \
--cc=shenyang39@huawei.com \
--cc=shiju.jose@huawei.com \
/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