| 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
| ||
|
Message-ID:
<PH3PPFD6B8A798DF19256C2DECDE23327709639A@PH3PPFD6B8A798D.namprd11.prod.outlook.com>
Date: Tue, 26 Aug 2025 07:01:13 +0000
From: "He, Rui" <Rui.He@...driver.com>
To: Bjorn Helgaas <helgaas@...nel.org>
CC: Bjorn Helgaas <bhelgaas@...gle.com>,
"linux-pci@...r.kernel.org"
<linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
"Chikhalkar, Prashant"
<Prashant.Chikhalkar@...driver.com>,
"Xiao, Jiguang"
<Jiguang.Xiao@...driver.com>
Subject: RE: [PATCH 1/1] pci: Add subordinate check before pci_add_new_bus()
> -----Original Message-----
> From: Bjorn Helgaas <helgaas@...nel.org>
> Sent: 2025年8月15日 22:23
> To: He, Rui <Rui.He@...driver.com>
> Cc: Bjorn Helgaas <bhelgaas@...gle.com>; linux-pci@...r.kernel.org;
> linux-kernel@...r.kernel.org; Chikhalkar, Prashant
> <Prashant.Chikhalkar@...driver.com>; Xiao, Jiguang
> <Jiguang.Xiao@...driver.com>
> Subject: Re: [PATCH 1/1] pci: Add subordinate check before pci_add_new_bus()
>
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> On Fri, Aug 15, 2025 at 02:31:31AM +0000, He, Rui wrote:
> > > -----Original Message-----
> > > From: Bjorn Helgaas <helgaas@...nel.org>
> > > Sent: 2025年8月15日 4:36
> > > To: He, Rui <Rui.He@...driver.com>
> > > Cc: Bjorn Helgaas <bhelgaas@...gle.com>; linux-pci@...r.kernel.org;
> > > linux-kernel@...r.kernel.org; Chikhalkar, Prashant
> > > <Prashant.Chikhalkar@...driver.com>; Xiao, Jiguang
> > > <Jiguang.Xiao@...driver.com>
> > > Subject: Re: [PATCH 1/1] pci: Add subordinate check before
> > > pci_add_new_bus()
> > >
> > > CAUTION: This email comes from a non Wind River email account!
> > > Do not click links or open attachments unless you recognize the
> > > sender and know the content is safe.
> > >
> > > On Thu, Aug 14, 2025 at 05:39:37PM +0800, Rui He wrote:
> > > > For preconfigured PCI bridge, child bus created on the first scan.
> > > > While for some reasons(e.g register mutation), the secondary, and
> > > > subordiante register reset to 0 on the second scan, which caused
> > > > to create PCI bus twice for the same PCI device.
> > >
> > > I don't quite follow this. Do you mean something is changing the
> > > bridge configuration between the first and second scans?
> >
> > I'm not sure what changed the bridge configuration, but the secondary
> > and subordinate is indeed 0 on the second scan as [bus 0e-10] created
> > for 0000:0b:01.0.
> >
> > In my opinion, it might be an invalid communication or register
> > mutation in PCI bridge.
>
> > > > Following is the related log:
> > > > [Wed May 28 20:38:36 CST 2025] pci 0000:0b:01.0: PCI bridge to
> > > > [bus 0d] [Wed May 28 20:38:36 CST 2025] pci 0000:0b:05.0: bridge
> > > > configuration invalid ([bus 00-00]), reconfiguring [Wed May 28
> > > > 20:38:36 CST 2025] pci 0000:0b:01.0: PCI bridge to [bus 0e-10]
> > > > [Wed May 28 20:38:36 CST 2025] pci 0000:0b:05.0: PCI bridge to
> > > > [bus 0f-10]
>
> > > > Here PCI device 000:0b:01.0 assigend to bus 0d and 0e.
> > >
> > > It looks like the [bus 0f-10] range is assigned to both bridges
> > > (0b:01.0 and 0b:05.0), which would definitely be a problem.
> > >
> > > I'm surprised that we haven't tripped over this before, and I'm
> > > curious about how we got here. Can you set CONFIG_DYNAMIC_DEBUG=y,
> > > boot with the dyndbg="file drivers/pci/*
> > > +p" kernel parameter, and collect the complete dmesg log?
> >
> > Sorry, as this is a individual issue, and cannot be reproduced, I
> > cannot offer more detailed logs.
>
> Do you have the complete dmesg log from this one time you saw the problem?
>
> As-is, I don't think there's quite enough here to move forward with this. I think
> we need some more detailed analysis to figure out how this happens.
>
> Bjorn
Attached is the dmesg logs while scan the PCI bus.
As the dmesg is customer sensitive, I have removed irrelevant logs and only kept the PCI enumeration logs that can be obtained.
Among that, "Quirks: Set bus range to 0xAABBCC" is printed by the custom hook declared through DECLARE_PCI_FIXUP_EARLY() in drvivers/pci/quirks.c.
0xAABBCC refers to the predefined PIC bridge Subordinate Bus Number, Secondary Bus Number, and Primary Bus Number.
Through the logs, [bus 0d 0e 0c] is created for pci device 0000:0b:01.0, but when removing PCI device 0000:0b:01.0, only bus 0c is removed, bus 0d 0e is still there.
Following is the related logs of "lspci"
# lspci -tv
......
\-[0000:00]-+-00.0 Intel Corporation Xeon E7 v3/Xeon E5 v3/Core i7 DMI2
+-03.1-[08-73]----00.0-[09-73]--+-00.0 Microsemi / PMC / IDT PES24NT24G2 PCI Express Switch
| +-02.0-[0a-10]----00.0-[0b-10]--+-01.0-[0d]----00.0 Device xxxx
| | +-04.0 PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch
| | +-05.0-[00]--
| | +-07.0-[00]--
| | \-09.0-[00]--
| +-03.0-[11-17]----00.0-[12-17]--+-01.0-[14]----00.0 Device xxxx
| | +-04.0 PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch
| | +-05.0-[00]--
| | +-07.0-[00]--
| | \-09.0-[00]--
......
Thanks,
Rui
View attachment "dmesg-pci-scan.txt" of type "text/plain" (10955 bytes)
Powered by blists - more mailing lists