Re: [PATCH v21 1/4] PCI: Allow per function PCI slots to fix slot reset on s390

[Farhan Ali <alifm@linux.ibm.com>]

On 7/15/2026 4:34 PM, Bjorn Helgaas wrote:
>> On s390 systems, which use a machine level hypervisor, PCI devices are
>> always accessed through a form of PCI pass-through which fundamentally
>> operates on a per PCI function granularity. This is also reflected in the
>> s390 PCI hotplug driver which creates hotplug slots for individual PCI
>> functions. Its reset_slot() function, which is a wrapper for
>> zpci_hot_reset_device(), thus also resets individual functions.
>>
>> Currently, the kernel's PCI_SLOT() macro assigns the same pci_slot object
>> to multifunction devices.
> PCI_SLOT() doesn't assign pci_slot objects; I guess they're assigned
> by some code that*uses* PCI_SLOT().  Since this says "currently," I
> assume you're changing that code, so we should mention where it is to
> help readers out.

Thanks for your response! I can re-word the commit message, how about 
something like this:

Currently, the pci_create_slot() assigns the same pci_slot object to 
multifunction devices.


>
> I see some Sashiko comments; those also need to be addressed or
> explained away.

Regarding Sashiko's comments for this patch, it mentions 2 issues:

New issues: - [High] Unconditional enablement of `per_func_slot` on S390 
breaks standard PCI hotplug (e.g., pciehp, shpchp) slot matching and 
resets.

I believe this is not applicable as on s390 we don't support any other 
PCI hotplug drivers given the unique nature of zPCI architecture.

Pre-existing issues:
- [High] Lockless access to `dev->slot` in `pci_dev_reset_slot_function` 
can lead to Use-After-Free if a hotplug driver is concurrently unbound.

Sashiko identified this as a pre-existing issue, so I don't think should 
be addressed with this patch.


Thanks

Farhan