Re: [PATCH v9 1/9] PCI: Allow per function PCI slots
From: Farhan Ali
Date: Tue Feb 17 2026 - 17:26:22 EST
On 2/17/2026 1:14 PM, Keith Busch wrote:
On Tue, Feb 17, 2026 at 10:22:49AM -0800, Farhan Ali wrote:
Currently, the kernel's PCI_SLOT() macro assigns the same pci_slot objectI think leakage is because s390 is passing in devfn when pci_create_slot
to multifunction devices. This approach worked fine on s390 systems that
only exposed virtual functions as individual PCI domains to the operating
system. Since commit 44510d6fa0c0 ("s390/pci: Handling multifunctions")
s390 supports exposing the topology of multifunction PCI devices by
grouping them in a shared PCI domain. When attempting to reset a function
through the hotplug driver, the shared slot assignment causes the wrong
function to be reset instead of the intended one. It also leaks memory as
we do create a pci_slot object for the function, but don't correctly free
it in pci_slot_release().
is expecting devnr, so things are not getting matched and assigned as
expected.
If you're able to make this change, it will clash with one existing
thing, and another proposal I've got at v5 now(*). Specifically, this
would allow all 8 bits to be used for the pci_slot 'number' when it's
currently expected to be limited to 5 bits. 0xff is special, and I'm
proposing another special value. If we are going to allow the slot
numbers to use all 8 bits, I think we need to change the type from u8 to
u16 so that there is space to encode such special values.
* https://lore.kernel.org/linux-pci/20260217160836.2709885-3-kbusch@xxxxxxxx/
I am open to suggestions on how we can better model a pci_slot per function. And yeah, I think it makes sense to update the pci_slot 'number' to u16.
Thanks
Farhan