[PATCH v3 0/2] liveupdate: prevent double preservation

[PATCH v3 0/2] liveupdate: prevent double preservation

[Pasha Tatashin]

Currently, LUO does not prevent the same file from being preserved twice
across different active sessions.

Because LUO preserves files of absolutely different types: memfd, and
upcoming vfiofd [1], iommufd [2], guestmefd (and possible kvmfd/cpufd).
There is no common private data or guarantee on how to prevent that the
same file is not preserved twice beside using inode or some slower and
expensive method like hashtables.

[1] https://lore.kernel.org/all/20260129212510.967611-1-dmatlack@google.com
[2] https://lore.kernel.org/all/20260203220948.2176157-1-skhawaja@google.com

Changelog:
v3:
 - Renamed luo_preserved_files_xa to luo_preserved_files (Mike)
 - Added xa inserts during restoration, so a file that is not yet finished is
   not preserved at the same time. (Sashiko)
v2:
 - Because inodes of preserved files can be shared, we cannot rely on a
   flag in the inode. Therefore, use an xarray to prevent preserving
   duplicated files.

Pasha Tatashin (2):
  liveupdate: prevent double management of files
  selftests: liveupdate: add test for double preservation

 kernel/liveupdate/luo_file.c                  | 26 ++++++++++--
 .../testing/selftests/liveupdate/liveupdate.c | 41 +++++++++++++++++++
 2 files changed, 64 insertions(+), 3 deletions(-)


base-commit: 785f0eb2f85decbe7c1ef9ae922931f0194ffc2e
-- 
2.43.0

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

[Pasha Tatashin]

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>
---
 kernel/liveupdate/luo_file.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c
index a38ea4975824..d1bb4213fd14 100644
--- a/kernel/liveupdate/luo_file.c
+++ b/kernel/liveupdate/luo_file.c
@@ -110,11 +110,15 @@
 #include <linux/sizes.h>
 #include <linux/slab.h>
 #include <linux/string.h>
+#include <linux/xarray.h>
 #include "luo_internal.h"
 
 static DECLARE_RWSEM(luo_file_handler_lock);
 static LIST_HEAD(luo_file_handler_list);
 
+/* Keep track of files being preserved by LUO */
+static DEFINE_XARRAY(luo_preserved_files);
+
 /* 2 4K pages, give space for 128 files per file_set */
 #define LUO_FILE_PGCNT		2ul
 #define LUO_FILE_MAX							\
@@ -249,6 +253,7 @@ static bool luo_token_is_used(struct luo_file_set *file_set, u64 token)
  * Context: Can be called from an ioctl handler during normal system operation.
  * Return: 0 on success. Returns a negative errno on failure:
  *         -EEXIST if the token is already used.
+ *         -EBUSY if the file descriptor is already preserved by another session.
  *         -EBADF if the file descriptor is invalid.
  *         -ENOSPC if the file_set is full.
  *         -ENOENT if no compatible handler is found.
@@ -277,6 +282,11 @@ int luo_preserve_file(struct luo_file_set *file_set, u64 token, int fd)
 	if (err)
 		goto  err_fput;
 
+	err = xa_insert(&luo_preserved_files, (unsigned long)file,
+			file, GFP_KERNEL);
+	if (err)
+		goto err_free_files_mem;
+
 	err = -ENOENT;
 	scoped_guard(rwsem_read, &luo_file_handler_lock) {
 		list_private_for_each_entry(fh, &luo_file_handler_list, list) {
@@ -289,11 +299,11 @@ int luo_preserve_file(struct luo_file_set *file_set, u64 token, int fd)
 
 	/* err is still -ENOENT if no handler was found */
 	if (err)
-		goto err_free_files_mem;
+		goto err_erase_xa;
 
 	err = luo_flb_file_preserve(fh);
 	if (err)
-		goto err_free_files_mem;
+		goto err_erase_xa;
 
 	luo_file = kzalloc_obj(*luo_file);
 	if (!luo_file) {
@@ -323,6 +333,8 @@ int luo_preserve_file(struct luo_file_set *file_set, u64 token, int fd)
 	kfree(luo_file);
 err_flb_unpreserve:
 	luo_flb_file_unpreserve(fh);
+err_erase_xa:
+	xa_erase(&luo_preserved_files, (unsigned long)file);
 err_free_files_mem:
 	luo_free_files_mem(file_set);
 err_fput:
@@ -366,6 +378,7 @@ void luo_file_unpreserve_files(struct luo_file_set *file_set)
 		luo_file->fh->ops->unpreserve(&args);
 		luo_flb_file_unpreserve(luo_file->fh);
 
+		xa_erase(&luo_preserved_files, (unsigned long)luo_file->file);
 		list_del(&luo_file->list);
 		file_set->count--;
 
@@ -609,6 +622,10 @@ int luo_retrieve_file(struct luo_file_set *file_set, u64 token,
 	luo_file->file = args.file;
 	/* Get reference so we can keep this file in LUO until finish */
 	get_file(luo_file->file);
+
+	WARN_ON(xa_insert(&luo_preserved_files, (unsigned long)luo_file->file,
+			  luo_file->file, GFP_KERNEL));
+
 	*filep = luo_file->file;
 	luo_file->retrieve_status = 1;
 
@@ -704,8 +721,11 @@ int luo_file_finish(struct luo_file_set *file_set)
 
 		luo_file_finish_one(file_set, luo_file);
 
-		if (luo_file->file)
+		if (luo_file->file) {
+			xa_erase(&luo_preserved_files,
+				 (unsigned long)luo_file->file);
 			fput(luo_file->file);
+		}
 		list_del(&luo_file->list);
 		file_set->count--;
 		mutex_destroy(&luo_file->mutex);
-- 
2.43.0

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

[Mike Rapoport]

On Wed, Mar 25, 2026 at 06:20:25PM +0000, 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>

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
>  kernel/liveupdate/luo_file.c | 26 +++++++++++++++++++++++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
 
-- 
Sincerely yours,
Mike.

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

[Pratyush Yadav]

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

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

[David Matlack]

On Wed, Mar 25, 2026 at 1:20 PM Pratyush Yadav <pratyush@kernel.org> wrote:

> 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 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.

I think LUO can still enforce that the file is not preserved twice.
HugeTLB and memfd's preserve() functions just need to also check that
the associated inode has not already been preserved?

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

[Pasha Tatashin]

On Wed, Mar 25, 2026 at 4:34 PM David Matlack <dmatlack@google.com> wrote:
>
> On Wed, Mar 25, 2026 at 1:20 PM Pratyush Yadav <pratyush@kernel.org> wrote:
>
> > 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.

Hm.

>
> > 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.
>
> I think LUO can still enforce that the file is not preserved twice.
> HugeTLB and memfd's preserve() functions just need to also check that
> the associated inode has not already been preserved?

For memfd/hugetlbs the true state is in inode
For vfio/kvm the shared anonymous inode is just a dummy wrapper, and
the true state is in file->private_data.

I wonder if we could use the XArray to track inodes for standard
files, but track the struct file itself for anonymous files (we would
need a new function from FS that allows us to determine if "struct
file" has anonymous inode or not).

Pasha

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

[Pasha Tatashin]

On Wed, Mar 25, 2026 at 5:08 PM Pasha Tatashin
<pasha.tatashin@soleen.com> wrote:
>
> On Wed, Mar 25, 2026 at 4:34 PM David Matlack <dmatlack@google.com> wrote:
> >
> > On Wed, Mar 25, 2026 at 1:20 PM Pratyush Yadav <pratyush@kernel.org> wrote:
> >
> > > 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.
>
> Hm.
>
> >
> > > 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.
> >
> > I think LUO can still enforce that the file is not preserved twice.
> > HugeTLB and memfd's preserve() functions just need to also check that
> > the associated inode has not already been preserved?
>
> For memfd/hugetlbs the true state is in inode
> For vfio/kvm the shared anonymous inode is just a dummy wrapper, and
> the true state is in file->private_data.
>
> I wonder if we could use the XArray to track inodes for standard
> files, but track the struct file itself for anonymous files (we would
> need a new function from FS that allows us to determine if "struct
> file" has anonymous inode or not).

Actually, let's not modify the fs layer, instead, add an optional
get_id(struct file *file) callback to the luo file handler (struct
liveupdate_file_ops). This would return a unique deduplication key.
For example, the memfd callback would return (unsigned
long)file->f_inode. If get_id() is not implemented for a given
handler, the LUO would default to using the struct file pointer
directly

>
> Pasha

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

[Mike Rapoport]

On Wed, Mar 25, 2026 at 05:08:57PM -0400, Pasha Tatashin wrote:
> On Wed, Mar 25, 2026 at 4:34 PM David Matlack <dmatlack@google.com> wrote:
> >
> > On Wed, Mar 25, 2026 at 1:20 PM Pratyush Yadav <pratyush@kernel.org> wrote:
> >
> > > 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.
> 
> Hm.
> 
> >
> > > 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.
> >
> > I think LUO can still enforce that the file is not preserved twice.
> > HugeTLB and memfd's preserve() functions just need to also check that
> > the associated inode has not already been preserved?
> 
> For memfd/hugetlbs the true state is in inode
> For vfio/kvm the shared anonymous inode is just a dummy wrapper, and
> the true state is in file->private_data.
> 
> I wonder if we could use the XArray to track inodes for standard
> files, but track the struct file itself for anonymous files (we would
> need a new function from FS that allows us to determine if "struct
> file" has anonymous inode or not).

Don't all files we preserve use anon inodes?

How about we extend the fh->ops with a method that will return "unique"
object? 

	list_private_for_each_entry(fh, &luo_file_handler_list, list) {
		if (fh->ops->can_preserve(fh, file)) {
			unique_handle = fh->ops->unique_handle(fh, file);
			err = 0;
			break;
		}
	}

	xa_insert(&luo_preserved_objects, unique_handle,
		  (unsigned long)unique_handle, GFP_KERNEL);
 
> Pasha

-- 
Sincerely yours,
Mike.

[PATCH v3 2/2] selftests: liveupdate: add test for double preservation

[Pasha Tatashin]

Verify that a file can only be preserved once across all active
sessions. Attempting to preserve it a second time, whether in the same
or a different session, should fail with EBUSY.

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
 .../testing/selftests/liveupdate/liveupdate.c | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/tools/testing/selftests/liveupdate/liveupdate.c b/tools/testing/selftests/liveupdate/liveupdate.c
index c2878e3d5ef9..37c808fbe1e9 100644
--- a/tools/testing/selftests/liveupdate/liveupdate.c
+++ b/tools/testing/selftests/liveupdate/liveupdate.c
@@ -345,4 +345,45 @@ TEST_F(liveupdate_device, preserve_unsupported_fd)
 	ASSERT_EQ(close(session_fd), 0);
 }
 
+/*
+ * Test Case: Prevent Double Preservation
+ *
+ * Verifies that a file (memfd) can only be preserved once across all active
+ * sessions. Attempting to preserve it a second time, whether in the same or
+ * a different session, should fail with EBUSY.
+ */
+TEST_F(liveupdate_device, prevent_double_preservation)
+{
+	int session_fd1, session_fd2, mem_fd;
+	int ret;
+
+	self->fd1 = open(LIVEUPDATE_DEV, O_RDWR);
+	if (self->fd1 < 0 && errno == ENOENT)
+		SKIP(return, "%s does not exist", LIVEUPDATE_DEV);
+	ASSERT_GE(self->fd1, 0);
+
+	session_fd1 = create_session(self->fd1, "double-preserve-session-1");
+	ASSERT_GE(session_fd1, 0);
+	session_fd2 = create_session(self->fd1, "double-preserve-session-2");
+	ASSERT_GE(session_fd2, 0);
+
+	mem_fd = memfd_create("test-memfd", 0);
+	ASSERT_GE(mem_fd, 0);
+
+	/* First preservation should succeed */
+	ASSERT_EQ(preserve_fd(session_fd1, mem_fd, 0x1111), 0);
+
+	/* Second preservation in a different session should fail with EBUSY */
+	ret = preserve_fd(session_fd2, mem_fd, 0x2222);
+	EXPECT_EQ(ret, -EBUSY);
+
+	/* Second preservation in the same session (different token) should fail with EBUSY */
+	ret = preserve_fd(session_fd1, mem_fd, 0x3333);
+	EXPECT_EQ(ret, -EBUSY);
+
+	ASSERT_EQ(close(mem_fd), 0);
+	ASSERT_EQ(close(session_fd1), 0);
+	ASSERT_EQ(close(session_fd2), 0);
+}
+
 TEST_HARNESS_MAIN
-- 
2.43.0

Re: [PATCH v3 0/2] liveupdate: prevent double preservation

[Andrew Morton]

On Wed, 25 Mar 2026 18:20:24 +0000 Pasha Tatashin <pasha.tatashin@soleen.com> wrote:

> Currently, LUO does not prevent the same file from being preserved twice
> across different active sessions.
> 
> Because LUO preserves files of absolutely different types: memfd, and
> upcoming vfiofd [1], iommufd [2], guestmefd (and possible kvmfd/cpufd).
> There is no common private data or guarantee on how to prevent that the
> same file is not preserved twice beside using inode or some slower and
> expensive method like hashtables.
> 

I updated mm.git's mm-new branch to this version.

> Changelog:
> v3:
>  - Renamed luo_preserved_files_xa to luo_preserved_files (Mike)
>  - Added xa inserts during restoration, so a file that is not yet finished is
>    not preserved at the same time. (Sashiko)

Below is how v3 altered mm.git.

It appears that some significant changes are in the works.  Please lmk
if there's actually value in keeping v3 under test, or should I just
drop it?



 kernel/liveupdate/luo_file.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

--- a/kernel/liveupdate/luo_file.c~b
+++ a/kernel/liveupdate/luo_file.c
@@ -117,7 +117,7 @@ static DECLARE_RWSEM(luo_file_handler_lo
 static LIST_HEAD(luo_file_handler_list);
 
 /* Keep track of files being preserved by LUO */
-static DEFINE_XARRAY(luo_preserved_files_xa);
+static DEFINE_XARRAY(luo_preserved_files);
 
 /* 2 4K pages, give space for 128 files per file_set */
 #define LUO_FILE_PGCNT		2ul
@@ -282,7 +282,7 @@ int luo_preserve_file(struct luo_file_se
 	if (err)
 		goto  err_fput;
 
-	err = xa_insert(&luo_preserved_files_xa, (unsigned long)file,
+	err = xa_insert(&luo_preserved_files, (unsigned long)file,
 			file, GFP_KERNEL);
 	if (err)
 		goto err_free_files_mem;
@@ -334,7 +334,7 @@ err_kfree:
 err_flb_unpreserve:
 	luo_flb_file_unpreserve(fh);
 err_erase_xa:
-	xa_erase(&luo_preserved_files_xa, (unsigned long)file);
+	xa_erase(&luo_preserved_files, (unsigned long)file);
 err_free_files_mem:
 	luo_free_files_mem(file_set);
 err_fput:
@@ -378,7 +378,7 @@ void luo_file_unpreserve_files(struct lu
 		luo_file->fh->ops->unpreserve(&args);
 		luo_flb_file_unpreserve(luo_file->fh);
 
-		xa_erase(&luo_preserved_files_xa, (unsigned long)luo_file->file);
+		xa_erase(&luo_preserved_files, (unsigned long)luo_file->file);
 		list_del(&luo_file->list);
 		file_set->count--;
 
@@ -622,6 +622,10 @@ int luo_retrieve_file(struct luo_file_se
 	luo_file->file = args.file;
 	/* Get reference so we can keep this file in LUO until finish */
 	get_file(luo_file->file);
+
+	WARN_ON(xa_insert(&luo_preserved_files, (unsigned long)luo_file->file,
+			  luo_file->file, GFP_KERNEL));
+
 	*filep = luo_file->file;
 	luo_file->retrieve_status = 1;
 
@@ -717,8 +721,11 @@ int luo_file_finish(struct luo_file_set
 
 		luo_file_finish_one(file_set, luo_file);
 
-		if (luo_file->file)
+		if (luo_file->file) {
+			xa_erase(&luo_preserved_files,
+				 (unsigned long)luo_file->file);
 			fput(luo_file->file);
+		}
 		list_del(&luo_file->list);
 		file_set->count--;
 		mutex_destroy(&luo_file->mutex);
_