Re: [PATCH v2 2/2] PCI: pciehp: Abort hot-plug if pci_hp_add_bridge() fails

[Lukas Wunner <lukas@wunner.de>]

On Mon, May 27, 2024 at 11:23:22AM +0200, Nam Cao wrote:
> On Mon, May 27, 2024 at 11:15:55AM +0200, Lukas Wunner wrote:
> > We already check for a NULL subordinate pointer in various places.
> > See e.g. commit 62e4492c3063 ("PCI: Prevent NULL dereference during
> > pciehp probe").
> 
> Ah, so bridge without subordinate bus is allowed in the kernel.
> 
> > If we're missing such checks, I'd suggest to add those.
> > 
> > If you believe having a NULL subordinate pointer is wrong and the
> > bridge should be de-enumerated altogether, I think you would have
> > to remove these NULL pointer checks as they'd otherwise become
> > pointless with your change.
> > 
> > Just adding missing NULL pointer checks seems to be the most
> > straightforward solution to me.
> 
> If the kernel do permits bridges without subordinate bus number, I am
> happy to go this direction. I expect going this way will require many more
> patches, I will dig into it and come back later.

It seems a lot of functions use a "if (dev->subordinate)" check
to distinguish between bridges and endpoints.

A bridge with a NULL subordinate pointer is then basically treated
like an endpoint.

There are places which use other ways to recognize bridges, e.g.
by looking at dev->hdr_type.  Only these code paths will have to
check for a NULL subordinate pointer.  In the case of pciehp,
portdrv binds to anything with class PCI_CLASS_BRIDGE_PCI_NORMAL,
without consideration for the subordinate pointer, hence a check
was needed in pciehp.

pciehp is used a lot by Thunderbolt/USB4, SD 7.0 and for NVMe drives.
I think shpchp isn't used as much, so its code paths aren't exercised
as heavily and bugs aren't found and fixed as quickly.  So chances are
that more checks are missing in shpchp than in pciehp.

Thanks,

Lukas