Re: [PATCH v4 4/4] s390/pci: Fence FMB enable/disable via sysfs for passthrough devices

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch explicitly wraps a sleepable user-space memory copy (`kstrtoul_from_user()`) inside `mutex_lock(&zdev->kzdev_lock)`, introducing a lock-holding anti-pattern that can block system paths.
--

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

s390/pci: Fence FMB enable/disable via sysfs for passthrough devices

This commit introduces a fence over enabling or disabling FMB via sysfs when
the zPCI device is associated with a KVM guest. This prevents the host from
disabling FMB while the guest is using it, securing the VM state.

> diff --git a/arch/s390/pci/pci_debug.c b/arch/s390/pci/pci_debug.c
> --- a/arch/s390/pci/pci_debug.c
> +++ b/arch/s390/pci/pci_debug.c
> @@ -149,9 +149,15 @@ static ssize_t pci_perf_seq_write(struct file *file, const char __user *ubuf,
>  	if (!zdev)
>  		return 0;
>  
> +	mutex_lock(&zdev->kzdev_lock);
> +	if (zdev->kzdev) {
> +		rc = -EPERM;
> +		goto out_unlock_kzdev;
> +	}
> +
>  	rc = kstrtoul_from_user(ubuf, count, 10, &val);

[Severity: Medium]
Is it necessary to hold kzdev_lock while copying from user-space?

Calling kstrtoul_from_user() here means we are holding the kzdev_lock mutex
during a potentially blocking memory copy. If the user-space read blocks, it
will indefinitely hold kzdev_lock, stalling any other operations
synchronizing on this device's lock.

Since kstrtoul_from_user() only parses data into a local stack variable and
does not depend on the device state, does it make sense to move this call
before acquiring kzdev_lock?

>  	if (rc)
> -		return rc;
> +		goto out_unlock_kzdev;

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