From: sashiko-bot@kernel.org
To: "Vipin Sharma" <vipinsh@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v5 06/20] vfio/pci: Preserve vfio-pci device files across Live Update
Date: Tue, 14 Jul 2026 15:36:28 +0000 [thread overview]
Message-ID: <20260714153628.CAADD1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714151505.3466855-7-vipinsh@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Lockless checks of `vfio_pci_dev_is_frozen()` in IOCTL and read/write handlers allow userspace to bypass the freeze state, breaking kexec handoff guarantees.
- [Medium] `vdev->liveupdate_frozen` is never cleared and `unfreeze` is unimplemented, permanently bricking the VFIO device if a kexec aborts.
--
--- Patch [6]: [PATCH v5 06/20] vfio/pci: Preserve vfio-pci device files across Live Update ---
commit 03e42ce3ade0f06aa286a1a8cacc4d3f5d2537c0
Author: Vipin Sharma <vipinsh@google.com>
vfio/pci: Preserve vfio-pci device files across Live Update
This commit implements the Live Update file handler callbacks to preserve a
vfio-pci device across a Live Update. It serializes device state into
vfio_pci_core_device_ser and resets the device during the freeze phase.
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index f31e59e5badb4..c312b0eaf7d00 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
[ ... ]
> @@ -1513,6 +1516,9 @@ long vfio_pci_core_ioctl(struct vfio_device *core_vdev, unsigned int cmd,
> container_of(core_vdev, struct vfio_pci_core_device, vdev);
> void __user *uarg = (void __user *)arg;
>
> + if (vfio_pci_dev_is_frozen(vdev))
> + return -EIO;
> +
[Severity: High]
Can a userspace thread race with the freeze operation here?
If a thread locklessly evaluates vfio_pci_dev_is_frozen() as false and then
blocks waiting for vdev->igate or vdev->memory_lock, couldn't
vfio_pci_liveupdate_freeze() concurrently acquire those locks, freeze the
device, set liveupdate_frozen to true, and release the locks?
The ioctl thread would then wake up, acquire the lock, and modify the frozen
device's state.
> diff --git a/drivers/vfio/pci/vfio_pci_liveupdate.c b/drivers/vfio/pci/vfio_pci_liveupdate.c
> index 803528c9f1b27..e6eb7f6b53d7f 100644
> --- a/drivers/vfio/pci/vfio_pci_liveupdate.c
> +++ b/drivers/vfio/pci/vfio_pci_liveupdate.c
[ ... ]
> @@ -6,28 +6,221 @@
> +static int vfio_pci_liveupdate_freeze(struct liveupdate_file_op_args *args)
> +{
[ ... ]
> + /*
> + * Userspace cannot use the FD correctly now irrespective of liveupdate
> + * freeze failing or succeeding. They will have to reinitialize the VFIO
> + * device to continue using it as reset might have loaded default PCI
> + * state. Disable ioctl, read, write and mmap access to the device.
> + */
> + smp_store_release(&vdev->liveupdate_frozen, true);
> + return 0;
> +}
[Severity: Medium]
Does this permanently brick the VFIO device if a kexec aborts?
The liveupdate_frozen flag is set to true here, but it looks like there is
no corresponding clear on device close/open or kexec abort.
Because the unfreeze operation callback in vfio_pci_liveupdate_file_ops is
unimplemented, the flag would remain set. Userspace attempting to recover
by closing and reopening the FD would continue to receive -EIO until the
driver is unbound.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714151505.3466855-1-vipinsh@google.com?part=6
next prev parent reply other threads:[~2026-07-14 15:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 15:14 [PATCH v5 00/20] vfio/pci: Base Live Update support for VFIO Vipin Sharma
2026-07-14 15:14 ` [PATCH v5 01/20] vfio/pci: Factor out the reset logic in VFIO PCI device close path Vipin Sharma
2026-07-14 15:14 ` [PATCH v5 02/20] vfio: Export various helpers from VFIO Vipin Sharma
2026-07-14 15:30 ` sashiko-bot
2026-07-14 15:14 ` [PATCH v5 03/20] vfio/pci: Export vfio_pci_dma_buf_move for vfio-pci module Vipin Sharma
2026-07-14 15:14 ` [PATCH v5 04/20] liveupdate: Export symbols needed by modules Vipin Sharma
2026-07-14 15:14 ` [PATCH v5 05/20] vfio/pci: Register a file handler with Live Update Orchestrator Vipin Sharma
2026-07-14 15:28 ` sashiko-bot
2026-07-14 15:14 ` [PATCH v5 06/20] vfio/pci: Preserve vfio-pci device files across Live Update Vipin Sharma
2026-07-14 15:36 ` sashiko-bot [this message]
2026-07-14 15:14 ` [PATCH v5 07/20] vfio: Introduce vfio_find_device() helper Vipin Sharma
2026-07-14 15:14 ` [PATCH v5 08/20] vfio: Refactor vfio_device_fops_cdev_open() Vipin Sharma
2026-07-14 15:14 ` [PATCH v5 09/20] vfio: Add API to open cdev device for Live Update restore Vipin Sharma
2026-07-14 15:14 ` [PATCH v5 10/20] vfio/pci: Retrieve preserved device files after Live Update Vipin Sharma
2026-07-14 15:14 ` [PATCH v5 11/20] vfio: Enforce preserved devices are retrieved via LIVEUPDATE_SESSION_RETRIEVE_FD Vipin Sharma
2026-07-14 15:28 ` sashiko-bot
2026-07-14 15:14 ` [PATCH v5 12/20] docs: liveupdate: Add documentation for VFIO PCI Vipin Sharma
2026-07-14 15:14 ` [PATCH v5 13/20] vfio: selftests: Build liveupdate library in VFIO selftests Vipin Sharma
2026-07-14 15:20 ` sashiko-bot
2026-07-14 15:14 ` [PATCH v5 14/20] vfio: selftests: Add vfio_pci_liveupdate_uapi_test Vipin Sharma
2026-07-14 15:44 ` sashiko-bot
2026-07-14 15:15 ` [PATCH v5 15/20] vfio: selftests: Initialize vfio_pci_device using a VFIO cdev FD Vipin Sharma
2026-07-14 15:15 ` [PATCH v5 16/20] vfio: selftests: Add Makefile support for TEST_GEN_PROGS_EXTENDED Vipin Sharma
2026-07-14 15:15 ` [PATCH v5 17/20] vfio: selftests: Add vfio_pci_liveupdate_kexec_test Vipin Sharma
2026-07-14 15:35 ` sashiko-bot
2026-07-14 15:15 ` [PATCH v5 18/20] vfio: selftests: Expose iommu_modes to tests Vipin Sharma
2026-07-14 15:15 ` [PATCH v5 19/20] vfio: selftests: Verify that opening VFIO device fails during Live Update Vipin Sharma
2026-07-14 15:42 ` sashiko-bot
2026-07-14 15:15 ` [PATCH v5 20/20] vfio: selftests: Add continuous DMA to vfio_pci_liveupdate_kexec_test Vipin Sharma
2026-07-14 15:37 ` sashiko-bot
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=20260714153628.CAADD1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vipinsh@google.com \
/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