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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Unconditional `per_func_slot = 1` assignment on s390 globally redefines PCI slot matching semantics, breaking standard PCI hotplug and slot topologies.

Pre-existing issues:
- [High] Lockless access to `dev->slot` in `pci_dev_reset_slot_function` allows a TOCTOU NULL pointer dereference and Use-After-Free if the slot is concurrently destroyed.
--

--- Patch [1]: [PATCH v22 1/4] PCI: Allow per function PCI slots to fix slot reset on s390 ---
commit 9361e1530ed79c09b88218431e8f5dd3bd89d63a
Author: Farhan Ali <alifm@linux.ibm.com>

PCI: Allow per function PCI slots to fix slot reset on s390

This patch introduces a per_func_slot flag for pci_slot to support per-function
PCI slots on s390 systems managed by a hypervisor. It updates the slot
assignment and hotplug reset logic to account for these per-function slots.

Cc: stable@vger.kernel.org
Suggested-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Farhan Ali <alifm@linux.ibm.com>

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c

[ ... ]

> @@ -4897,8 +4897,9 @@ static int pci_reset_hotplug_slot(struct hotplug_slot *hotplug, bool probe)
>  
>  static int pci_dev_reset_slot_function(struct pci_dev *dev, bool probe)
>  {
> -	if (dev->multifunction || dev->subordinate || !dev->slot ||
> -	    dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET)
> +	if (dev->subordinate || !dev->slot ||
> +	    dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET ||
> +	    (dev->multifunction && !dev->slot->per_func_slot))

[Severity: High]
This is a pre-existing issue, but does adding dev->slot->per_func_slot here
exacerbate a race condition?

Looking at pci_dev_reset_slot_function(), dev->slot is accessed locklessly
and without READ_ONCE(). If a hotplug driver module is unloaded concurrently,
it can call pci_destroy_slot() which triggers pci_slot_release().

Since pci_slot_release() takes pci_bus_sem for reading and sets
dev->slot = NULL before freeing the slot, an interleaving execution could
pass the !dev->slot check, and then attempt to dereference the freed pointer
when evaluating dev->slot->per_func_slot or dev->slot->hotplug.

>  		return -ENOTTY;
>  
>  	return pci_reset_hotplug_slot(dev->slot->hotplug, probe);

[ ... ]

> diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
> --- a/drivers/pci/slot.c
> +++ b/drivers/pci/slot.c

[ ... ]

> @@ -72,6 +72,23 @@ static ssize_t cur_speed_read_file(struct pci_slot *slot, char *buf)
>  	return bus_speed_read(slot->bus->cur_bus_speed, buf);
>  }
>  
> +static bool pci_dev_matches_slot(struct pci_dev *dev, struct pci_slot *slot)
> +{
> +	if (slot->per_func_slot)
> +		return dev->devfn == slot->number;
> +
> +	return slot->number == PCI_SLOT_ALL_DEVICES ||
> +		PCI_SLOT(dev->devfn) == slot->number;
> +}
> +
> +static bool pci_slot_enabled_per_func(void)
> +{
> +	if (IS_ENABLED(CONFIG_S390))
> +		return true;

[Severity: High]
Could this unconditional check cause issues for standard PCI hotplug drivers
on s390?

Because pci_slot_enabled_per_func() returns true globally when CONFIG_S390
is enabled, every slot created via pci_create_slot() on s390 will have
per_func_slot set to 1.

When generic hotplug drivers (like pciehp) attempt to match devices
using the PCI_SLOT_ALL_DEVICES (0xfeff) wildcard, pci_dev_matches_slot()
will take the early return:

drivers/pci/slot.c:pci_dev_matches_slot() {
    if (slot->per_func_slot)
        return dev->devfn == slot->number;
    ...
}

Since dev->devfn is an 8-bit value, it will never match 0xfeff. Would this
break device matching for standard hotplug slots (like KVM guests) on s390
by bypassing the wildcard check entirely?

> +
> +	return false;
> +}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720192505.2957-1-alifm@linux.ibm.com?part=1