From: sashiko-bot@kernel.org
To: "Farhan Ali" <alifm@linux.ibm.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v18 3/4] vfio/pci: Add a reset_done callback for vfio-pci driver
Date: Wed, 03 Jun 2026 19:04:35 +0000 [thread overview]
Message-ID: <20260603190436.599761F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260603182415.2324-4-alifm@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] The `reset_done` callback breaks standard device resets by irreversibly overwriting the runtime PCI configuration space.
- [High] Concurrent execution of `vfio_pci_core_aer_reset_done` and `vfio_pci_core_disable` leads to a Use-After-Free on `vdev->pci_saved_state`.
- [High] The `reset_done` callback is never invoked during AER error recovery.
--
commit ea3a78b14c5b561020bd16d25cbb09f0536e6e7a
Author: Farhan Ali <alifm@linux.ibm.com>
vfio/pci: Add a reset_done callback for vfio-pci driver
On error recovery for a PCI device bound to vfio-pci driver, we want to
recover the state of the device to its last known saved state. The callback
restores the state of the device to its initial saved state.
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index 27642f10fe973..95af3e827ee05 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -2290,6 +2290,17 @@ pci_ers_result_t vfio_pci_core_aer_err_detected(struct pci_dev *pdev,
> }
> EXPORT_SYMBOL_GPL(vfio_pci_core_aer_err_detected);
>
> +static void vfio_pci_core_aer_reset_done(struct pci_dev *pdev)
> +{
> + struct vfio_pci_core_device *vdev = dev_get_drvdata(&pdev->dev);
> +
> + if (!vdev->pci_saved_state)
> + return;
[Severity: High]
Can this race with vfio_pci_core_disable() and cause a use-after-free on
vdev->pci_saved_state?
When a user closes the device fd, vfio_pci_core_disable() is invoked:
vfio_pci_core_disable()
pci_load_and_free_saved_state(pdev, &vdev->pci_saved_state);
This frees the memory and sets the pointer to NULL without holding the PCI
device_lock.
Concurrently, if a system-initiated function reset occurs, the PCI core
holds device_lock and invokes this reset_done callback via
pci_dev_restore().
Because there is no common lock between these two paths, can the pointer be
freed by vfio_pci_core_disable() immediately after the NULL check here, but
before it is dereferenced in pci_load_saved_state()?
> +
> + pci_load_saved_state(pdev, vdev->pci_saved_state);
> + pci_restore_state(pdev);
[Severity: Critical]
Does this unintentionally overwrite the runtime PCI configuration space
during normal device resets?
The PCI core invokes reset_done at the end of standard PCI function resets
via pci_dev_restore(), which includes pci_try_reset_function() triggered by
the VFIO_DEVICE_RESET ioctl.
Normally, pci_try_reset_function() transparently saves the runtime state,
resets the device, and restores it.
However, restoring vdev->pci_saved_state here unconditionally applies the
state from when the device was initially opened. Could this revert all
runtime configuration changes made by a guest VM, such as BAR programming
and MSI-X enablement?
> +}
> +
> int vfio_pci_core_sriov_configure(struct vfio_pci_core_device *vdev,
> int nr_virtfn)
[ ... ]
> @@ -2354,6 +2365,7 @@ EXPORT_SYMBOL_GPL(vfio_pci_core_sriov_configure);
>
> const struct pci_error_handlers vfio_pci_core_err_handlers = {
> .error_detected = vfio_pci_core_aer_err_detected,
> + .reset_done = vfio_pci_core_aer_reset_done,
[Severity: High]
Will this callback actually be invoked during AER error recovery?
The commit message mentions restoring the device state during PCIe AER error
recovery. However, the AER core in pcie_do_recovery() coordinates recovery
by calling .error_detected, .mmio_enabled, .slot_reset, and .resume.
It uses low-level hardware resets like pci_bus_error_reset() or
pcie_reset_flr() which do not trigger the pci_dev_restore() wrapper.
Since reset_done is exclusively called from pci_dev_restore() during
standard function resets, does the state restoration logic belong in
.slot_reset instead to ensure it executes during an AER event?
> };
> EXPORT_SYMBOL_GPL(vfio_pci_core_err_handlers);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260603182415.2324-1-alifm@linux.ibm.com?part=3
next prev parent reply other threads:[~2026-06-03 19:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 18:24 [PATCH v18 0/4] [VFIO] Error recovery for vfio-pci devices on s390x Farhan Ali
2026-06-03 18:24 ` [PATCH v18 1/4] s390/pci: Store PCI error information for passthrough devices Farhan Ali
2026-06-03 22:20 ` Alex Williamson
[not found] ` <d352f011-3c47-475a-b0a3-6005e56ef21d@linux.ibm.com>
2026-06-04 18:27 ` Alex Williamson
2026-06-03 18:24 ` [PATCH v18 2/4] vfio-pci/zdev: Add a device feature for error information Farhan Ali
2026-06-03 18:49 ` sashiko-bot
2026-06-03 22:37 ` Alex Williamson
2026-06-03 23:40 ` Farhan Ali
2026-06-03 18:24 ` [PATCH v18 3/4] vfio/pci: Add a reset_done callback for vfio-pci driver Farhan Ali
2026-06-03 19:04 ` sashiko-bot [this message]
2026-06-03 22:46 ` Alex Williamson
2026-06-04 0:01 ` Farhan Ali
2026-06-04 8:28 ` Keith Busch
2026-06-04 17:17 ` Farhan Ali
2026-06-04 19:57 ` Alex Williamson
2026-06-08 19:26 ` Farhan Ali
2026-06-09 19:16 ` Alex Williamson
2026-06-09 20:13 ` Farhan Ali
2026-06-04 20:42 ` Keith Busch
2026-06-05 18:41 ` Farhan Ali
2026-06-09 21:38 ` Keith Busch
2026-06-03 18:24 ` [PATCH v18 4/4] vfio/pci: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEX Farhan Ali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260603190436.599761F00898@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alifm@linux.ibm.com \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox