Re: [PATCH v9 1/4] s390/pci: Hold fmb_lock when enabling or disabling PCI devices

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] s390/pci: race in pcibios_disable_device leaves FMB enabled
--

commit 0f2a2ae0e5e387c72b216a0f886fdb95698ac275
Author: Omar Elghoul <oelghoul@linux.ibm.com>

s390/pci: Hold fmb_lock when enabling or disabling PCI devices
    
Ensure that fmb_lock is held by pcibios_enable_device() and
pcibios_disable_device() when calling zpci_fmb_enable_device() or
zpci_fmb_disable_device(), respectively.

> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> index d64c544b32b0c..c055a9ad09724 100644
> --- a/arch/s390/pci/pci.c
> +++ b/arch/s390/pci/pci.c

[ ... ]

> @@ -648,7 +654,9 @@ void pcibios_disable_device(struct pci_dev *pdev)
>  {
>  	struct zpci_dev *zdev = to_zpci(pdev);
>  
> +	mutex_lock(&zdev->fmb_lock);
>  	zpci_fmb_disable_device(zdev);
> +	mutex_unlock(&zdev->fmb_lock);
>  	zpci_debug_exit_device(zdev);
>  }

[Severity: Medium]
Could this sequence allow a race condition with debugfs?

If a concurrent write to the debugfs statistics file occurs in the window
after mutex_unlock() but before zpci_debug_exit_device(), it appears it could
acquire fmb_lock and invoke zpci_fmb_enable_device().

If this happens, does it leave the FMB running in hardware without a debugfs
interface to control it, while also leaking the zdev->fmb memory?

Would it be safer to call zpci_debug_exit_device(zdev) before acquiring
fmb_lock?

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