Linux PCI subsystem development
 help / color / mirror / Atom feed
From: "Krzysztof Wilczyński" <kw@linux.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org,
	Wouter Bijlsma <wouter@wouterbijlsma.nl>,
	Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH] PCI/bwctrl: Fix NULL pointer deref on bus number exhaustion
Date: Sun, 23 Mar 2025 20:24:56 +0900	[thread overview]
Message-ID: <20250323112456.GA1902347@rocinante> (raw)
In-Reply-To: <3b6c8d973aedc48860640a9d75d20528336f1f3c.1742669372.git.lukas@wunner.de>

Hello,

> When BIOS neglects to assign bus numbers to PCI bridges, the kernel
> attempts to correct that during PCI device enumeration.  If it runs out
> of bus numbers, no pci_bus is allocated and the "subordinate" pointer in
> the bridge's pci_dev remains NULL.
> 
> The PCIe bandwidth controller erroneously does not check for a NULL
> subordinate pointer and dereferences it on probe.
> 
> Bandwidth control of unusable devices below the bridge is of questionable
> utility, so simply error out instead.  This mirrors what PCIe hotplug does
> since commit 62e4492c3063 ("PCI: Prevent NULL dereference during pciehp
> probe").
> 
> The PCI core emits a message with KERN_INFO severity if it has run out of
> bus numbers.  PCIe hotplug emits an additional message with KERN_ERR
> severity to inform the user that hotplug functionality is disabled at the
> bridge.  A similar message for bandwidth control does not seem merited,
> given that its only purpose so far is to expose an up-to-date link speed
> in sysfs and throttle the link speed on certain laptops with limited
> Thermal Design Power.  So error out silently.
> 
> User-visible messages:
> 
>   pci 0000:16:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>   [...]
>   pci_bus 0000:45: busn_res: [bus 45-74] end is updated to 74
>   pci 0000:16:02.0: devices behind bridge are unusable because [bus 45-74] cannot be assigned for them
>   [...]
>   pcieport 0000:16:02.0: pciehp: Hotplug bridge without secondary bus, ignoring
>   [...]
>   BUG: kernel NULL pointer dereference
>   RIP: pcie_update_link_speed
>   pcie_bwnotif_enable
>   pcie_bwnotif_probe
>   pcie_port_probe_service
>   really_probe

Applied to bwctrl, thank you!

	Krzysztof

  reply	other threads:[~2025-03-23 11:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-22 18:52 [PATCH] PCI/bwctrl: Fix NULL pointer deref on bus number exhaustion Lukas Wunner
2025-03-23 11:24 ` Krzysztof Wilczyński [this message]
     [not found]   ` <2e16d6af-7d7d-47a7-9c69-26f0765a83d6@app.fastmail.com>
2025-03-23 12:56     ` Krzysztof Wilczyński
2025-03-23 13:07       ` Wouter Bijlsma
2025-03-23 13:39         ` Krzysztof Wilczyński
2025-04-04 13:06       ` Ilpo Järvinen

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=20250323112456.GA1902347@rocinante \
    --to=kw@linux.com \
    --cc=helgaas@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mika.westerberg@linux.intel.com \
    --cc=wouter@wouterbijlsma.nl \
    /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