On Wed, Dec 3, 2025 at 7:55 AM Alex Mastro amastro@fb.com wrote:
On Wed, Nov 26, 2025 at 07:35:53PM +0000, David Matlack wrote:
From: Vipin Sharma vipinsh@google.com static int vfio_pci_liveupdate_retrieve(struct liveupdate_file_op_args *args) {
return -EOPNOTSUPP;
struct vfio_pci_core_device_ser *ser;struct vfio_device *device;struct folio *folio;struct file *file;int ret;folio = kho_restore_folio(args->serialized_data);if (!folio)return -ENOENT;Should this be consistent with the behavior of pci_flb_retrieve() which panics on failure? The short circuit failure paths which follow leak the folio, which seems like a hygiene issue, but the practical significance is moot if vfio_pci_liveupdate_retrieve() failure is catastrophic anyways?
pci_flb_retrieve() is used during boot. If it fails, we risk DMA corrupting any memory region, so a panic makes sense. In contrast, this retrieval happens once we are already in userspace, allowing the user to decide how to handle the failure to recover the preserved cdev.
Pasha
ser = folio_address(folio);device = vfio_find_device(ser, match_device);if (!device)return -ENODEV;/** During a Live Update userspace retrieves preserved VFIO cdev files by* issuing an ioctl on /dev/liveupdate rather than by opening VFIO* character devices.** To handle that scenario, this routine simulates opening the VFIO* character device for userspace with an anonymous inode. The returned* file has the same properties as a cdev file (e.g. operations are* blocked until BIND_IOMMUFD is called), aside from the inode* association.*/file = anon_inode_getfile_fmode("[vfio-device-liveupdate]",&vfio_device_fops, NULL,O_RDWR, FMODE_PREAD | FMODE_PWRITE);if (IS_ERR(file)) {ret = PTR_ERR(file);goto out;}ret = __vfio_device_fops_cdev_open(device, file);if (ret) {fput(file);goto out;}args->file = file;+out:
/* Drop the reference from vfio_find_device() */put_device(&device->device);return ret;+}