Re: [PATCH v16 4/7] s390/pci: Store PCI error information for passthrough devices

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unlocking an unheld mutex causes kernel panic.
- [High] Passthrough devices incorrectly fall back to host-level recovery if the error queue is full.
--

commit 016a2e8c9545102f4de3d94db360fafe625fa60b
Author: Farhan Ali <alifm@linux.ibm.com>

s390/pci: Store PCI error information for passthrough devices

This commit introduces a mechanism to store PCI error information for
passthrough devices on s390x so userspace can handle recovery. It removes
the dependency on struct kvm_zdev to detect passthrough devices and
introduces pending error tracking.

diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c
index 839bd91c056e5..ad273decb1c2b 100644
--- a/arch/s390/pci/pci_event.c
+++ b/arch/s390/pci/pci_event.c
[ ... ]
> +static int zpci_store_pci_error(struct pci_dev *pdev,
> +				 struct zpci_ccdf_err *ccdf)
> +{
> +	struct zpci_dev *zdev = to_zpci(pdev);
> +	int i;
> +
> +	guard(mutex)(&zdev->pending_errs_lock);
> +	if (!zdev->pending_errs.mediated_recovery)
> +		return -EINVAL;
> +
> +	if (zdev->pending_errs.count >= ZPCI_ERR_PENDING_MAX) {
> +		pr_err("%s: Maximum number (%d) of pending error events queued\n",
> +		       pci_name(pdev), ZPCI_ERR_PENDING_MAX);
> +		return -ENOMEM;
> +	}
[ ... ]
> @@ -216,12 +223,23 @@ static pci_ers_result_t zpci_event_attempt_error_recovery(struct pci_dev *pdev)
>  		goto out_unlock;
>  	}
>  
> +	mediated_recovery = zpci_store_pci_error(pdev, ccdf) == 0 ? true : false;

If zpci_store_pci_error() returns an error, such as -ENOMEM when the pending
error queue reaches ZPCI_ERR_PENDING_MAX, mediated_recovery evaluates to false.

Will this cause the function to bypass the passthrough early exit and fall
through to the host-level error recovery mechanisms below?

It appears this could result in a host-initiated reset on a device actively
passed through to userspace, which might break passthrough isolation.

> +
>  	ers_res = zpci_event_notify_error_detected(pdev, driver);
>  	if (ers_result_indicates_abort(ers_res)) {
>  		status_str = "failed (abort on detection)";
>  		goto out_unlock;
>  	}
>  
> +	if (mediated_recovery) {
> +		pr_info("%s: Leaving recovery of pass-through device to user-space\n",
> +			pci_name(pdev));
> +		ers_res = PCI_ERS_RESULT_RECOVERED;
> +		status_str = "in progress";
> +		mutex_unlock(&zdev->pending_errs_lock);

Does this unlock a mutex that is not currently held?

The zdev->pending_errs_lock is acquired and automatically released within
the scope of the zpci_store_pci_error() helper function using the
guard(mutex) macro.

Attempting to unlock an already-unlocked mutex usually results in a kernel
panic or lockdep warning.

> +		goto out_unlock;
> +	}

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