linux-kernel - Re: [PATCH 1/2] PCI: Setup bridge resources earlier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <310c8da6-6775-4c3c-b9b3-bad739cda46f@packett.cool>
Date: Sun, 12 Oct 2025 03:29:42 -0300
From: Val Packett <val@...kett.cool>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
 Krzysztof Wilczyński <kw@...ux.com>,
 "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
 LKML <linux-kernel@...r.kernel.org>,
 Lucas De Marchi <lucas.demarchi@...el.com>
Subject: Re: [PATCH 1/2] PCI: Setup bridge resources earlier

On 10/10/25 2:01 PM, Ilpo Järvinen wrote:

> [..]
> Even if you were very likely joking here, I'm still sorry for breaking it,
> no matter which company's device.
>
> Perhaps I'll start Cc you in all upcoming resource changes as you seem to
> be so willing to volunteer to review them. ;-D

Perhaps Intel corporate could pay me for QAing the patches :D

> There seem to be cases where pci_assign_unassigned_root_bus_resources()
> executes for bus 0000:04 before 0004:01:00.0 is scanned as it is only
> recorded later.
>
> Hmm, qcom_pcie_global_irq_thread() seems to indicate the real enumeration
> can only occur after the link up event has arrived, and it starts another
> scan from there.

Right, I've even seen things about the link-up sequence in the commits 
for the PCIe driver, e.g. 4581403f6792 ("PCI: qcom: Enumerate endpoints 
based on Link up event in 'global_irq' interrupt").

Is this really that uncommon? Can we be sure that other drivers don't 
behave similarly?

> Perhaps this could be solved by inhibiting resource sizing and assignment
> per host bridge until the bus could be enumerated for real. Otherwise the
> resource assignment has no idea how the bridge windows should be sized
> which then can lead to this cornering itself if the initial assignment
> without knowledge of the necessary sizes.
>
> Could you please try if the patch below helps?
> [..]
> @@ -1825,6 +1826,8 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>   		bridge->sysdata = cfg;
>   		bridge->ops = (struct pci_ops *)&pci_qcom_ecam_ops.pci_ops;
>   		bridge->msi_domain = true;
> +		// FIXME: Should this be specific to just some host bridges?
> +		bridge->enumeration_pending = 1;
>   
>   		ret = pci_host_probe(bridge);
>   		if (ret)

..and nope, particularly that assignment did not run because at least on 
x1e, the bridges are not firmware_managed, so they are enumerated normally.

~val