Re: [PATCH v3 1/2] liveupdate: prevent double management of files

[Pratyush Yadav <pratyush@kernel.org>]

Hi Pasha,

On Wed, Mar 25 2026, Pasha Tatashin wrote:

> Currently, LUO does not prevent the same file from being managed twice
> across different active sessions.
>
> Use a global xarray luo_preserved_files to keep track of file
> pointers being preserved by LUO. Update luo_preserve_file() to check and
> insert the file pointer into this xarray when it is preserved, and
> erase it in luo_file_unpreserve_files() when it is released.
>
> This ensures that the same file (struct file) cannot be managed by
> multiple sessions. If another session attempts to preserve an already
> managed file, it will now fail with -EBUSY.
>
> Acked-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>

For memfd and hugetlb at least, we serialize the _inode_ not the file.
The inode has the contents that we care to preserve.

So if two FDs point to the same inode, this will break. You can do this
by first creating a memfd and then by opening "/proc/self/fd/<fd>". Then
you would be able to trigger the preservation twice, causing all sorts
of problems. Same on the retrieve side.

So I think you should be storing the inode here.

Except... IOMMUFD and VFIO seem to be using different things for the
state that needs to be preserved. I don't know either of the subsystems
that well but from a quick look, I see that
iommufd_liveupdate_preserve() [0] calls iommufd_ctx_from_file() (which
stores the ictx in file->private_data) and does most of the preservation
operations on the ictx.

Similarly, vfio_pci_liveupdate_preserve() [1] calls
vfio_device_from_file(), which also uses file->private_data.

So, there seems to be no single way to get the "target object" that can
tell us whether it is already serialized or not. For memfd and hugetlb
it is the inode, for IOMMUFD it is the iommufd_ctx and for VFIO it is
the vfio_device.

So unless I am missing something, I don't think this approach will work.
As much as I hate to suggest it, I think we need to move this check to
each caller so they can find out the object they need to serialize and
check if it already is.

[0] https://github.com/samikhawaja/linux/blob/iommu/phase1-v1/drivers/iommu/iommufd/liveupdate.c#L210
[1] https://github.com/dmatlack/linux/blob/liveupdate/vfio/cdev/v3/drivers/vfio/pci/vfio_pci_liveupdate.c#L145

[...]

-- 
Regards,
Pratyush Yadav