mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH 0/2] memfd_luo: keep memfd frozen until finish
@ 2026-11-03 18:19 Pratyush Yadav
  2026-11-03 18:19 ` [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve " Pratyush Yadav
  2026-11-03 18:19 ` [PATCH 2/2] mm/memfd_luo: keep memfd frozen " Pratyush Yadav
  0 siblings, 2 replies; 5+ messages in thread
From: Pratyush Yadav @ 2026-11-03 18:19 UTC (permalink / raw)
  To: Pasha Tatashin, Mike Rapoport, Pratyush Yadav, Andrew Morton,
	Samiullah Khawaja
  Cc: kexec, linux-kernel, linux-mm

From: "Pratyush Yadav (Google)" <pratyush@kernel.org>

Hi,

This series keeps a retrieved memfd frozen until finish. The main
motivation is to let dependents like iommufd have a chance to acquire a
reference. It also fits conceptually: finish is the point when the file
should be back to "normal".

Patch 1 allows keeping private_data from retrieve to finish. This is
needed by memfd to keep hold of folios_ser, which it uses to give up its
pins.

Patch 2 does the main change.

The series is based on
https://lore.kernel.org/kexec/20261103172251.2348370-1-pratyush@kernel.org/T/#u.

Regards,
Pratyush Yadav

Pratyush Yadav (Google) (2):
  liveupdate: luo_file: allow keeping private_data from retrieve until
    finish
  mm/memfd_luo: keep memfd frozen until finish

 include/linux/liveupdate.h   |  8 ++--
 kernel/liveupdate/luo_file.c | 11 +++--
 mm/memfd_luo.c               | 87 ++++++++++++++++++++++++++++--------
 3 files changed, 81 insertions(+), 25 deletions(-)

-- 
2.56.0.385.gac671c819a-goog


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve until finish
  2026-11-03 18:19 [PATCH 0/2] memfd_luo: keep memfd frozen until finish Pratyush Yadav
@ 2026-11-03 18:19 ` Pratyush Yadav
  2026-11-03 20:35   ` Pasha Tatashin
  2026-11-03 18:19 ` [PATCH 2/2] mm/memfd_luo: keep memfd frozen " Pratyush Yadav
  1 sibling, 1 reply; 5+ messages in thread
From: Pratyush Yadav @ 2026-11-03 18:19 UTC (permalink / raw)
  To: Pasha Tatashin, Mike Rapoport, Pratyush Yadav, Andrew Morton,
	Samiullah Khawaja
  Cc: kexec, linux-kernel, linux-mm

From: "Pratyush Yadav (Google)" <pratyush@kernel.org>

The private_data field of struct liveupdate_file_op_args lets file
handlers keep runtime state that is not preserved. It is set by
.preserve() and passed to the later outgoing callbacks, up to
.unpreserve(). But in the new kernel, nothing set by .retrieve() is
kept, and .can_finish() and .finish() always get a NULL private_data.

Handlers might need to keep runtime state from retrieve until finish.
For example, memfd will need to remember the folios it holds on to
until finish so it can release them there.

Save the private_data set by a successful .retrieve() in the luo_file,
and pass it to .can_finish() and .finish(). The handler must free it in
.finish().

Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
---
 include/linux/liveupdate.h   |  8 +++++---
 kernel/liveupdate/luo_file.c | 11 ++++++++---
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
index 63ea5417de849..21caff8a98a7e 100644
--- a/include/linux/liveupdate.h
+++ b/include/linux/liveupdate.h
@@ -36,9 +36,11 @@ struct file;
  * @serialized_data:  The opaque u64 handle, preserve/prepare/freeze may update
  *                    this field.
  * @private_data:     Private data for the file used to hold runtime state that
- *                    is not preserved. Set by the handler's .preserve()
- *                    callback, and must be freed in the handler's
- *                    .unpreserve() callback.
+ *                    is not preserved. For outgoing, set by the handler's
+ *                    .preserve() callback, and must be freed in the handler's
+ *                    .unpreserve() callback. For incoming, set by the handler's
+ *                    .retrieve() callback on success, and must be freed in the
+ *                    handler's .finish() callback.
  *
  * This structure bundles all parameters for the file operation callbacks.
  * The 'data' and 'file' fields are used for both input and output.
diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c
index c39f96961a85b..ca4b685d6e1ce 100644
--- a/kernel/liveupdate/luo_file.c
+++ b/kernel/liveupdate/luo_file.c
@@ -130,9 +130,11 @@ static DEFINE_XARRAY(luo_preserved_files);
  *                 .retrieve(), and .finish() callbacks, allowing it to track
  *                 and update its serialized state across phases.
  * @private_data:  Pointer to the private data for the file used to hold runtime
- *                 state that is not preserved. Set by the handler's .preserve()
- *                 callback, and must be freed in the handler's .unpreserve()
- *                 callback.
+ *                 state that is not preserved. For outgoing, set by the
+ *                 handler's .preserve() callback, and must be freed in the
+ *                 handler's .unpreserve() callback. For incoming, set by the
+ *                 handler's .retrieve() callback, and must be freed in the
+ *                 handler's .finish() callback.
  * @retrieve_status: Status code indicating whether a user/kernel in the new kernel has
  *                 successfully called retrieve() on this file. This prevents
  *                 multiple retrieval attempts. A value of 0 means a retrieve()
@@ -596,6 +598,7 @@ int luo_retrieve_file(struct luo_file_set *file_set, u64 token,
 	}
 
 	luo_file->file = args.file;
+	luo_file->private_data = args.private_data;
 	/* Get reference so we can keep this file in LUO until finish */
 	get_file(luo_file->file);
 
@@ -622,6 +625,7 @@ static int luo_file_can_finish_one(struct luo_file_set *file_set,
 		args.handler = luo_file->fh;
 		args.file = luo_file->file;
 		args.serialized_data = luo_file->serialized_data;
+		args.private_data = luo_file->private_data;
 		args.retrieve_status = luo_file->retrieve_status;
 		can_finish = luo_file->fh->ops->can_finish(&args);
 	}
@@ -639,6 +643,7 @@ static void luo_file_finish_one(struct luo_file_set *file_set,
 	args.handler = luo_file->fh;
 	args.file = luo_file->file;
 	args.serialized_data = luo_file->serialized_data;
+	args.private_data = luo_file->private_data;
 	args.retrieve_status = luo_file->retrieve_status;
 
 	luo_file->fh->ops->finish(&args);
-- 
2.56.0.385.gac671c819a-goog


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH 2/2] mm/memfd_luo: keep memfd frozen until finish
  2026-11-03 18:19 [PATCH 0/2] memfd_luo: keep memfd frozen until finish Pratyush Yadav
  2026-11-03 18:19 ` [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve " Pratyush Yadav
@ 2026-11-03 18:19 ` Pratyush Yadav
  2026-11-03 20:35   ` Pasha Tatashin
  1 sibling, 1 reply; 5+ messages in thread
From: Pratyush Yadav @ 2026-11-03 18:19 UTC (permalink / raw)
  To: Pasha Tatashin, Mike Rapoport, Pratyush Yadav, Andrew Morton,
	Samiullah Khawaja
  Cc: kexec, linux-kernel, linux-mm

From: "Pratyush Yadav (Google)" <pratyush@kernel.org>

After a memfd is retrieved, it immediately goes back into "normal"
operation. The file comes back unfrozen, and its pages can migrate, it
can be truncated, and so on. If the memfd is depended on by something,
like iommufd, that can open a window for folios to move around before
the consumer can re-establish its references.

Finish is the conceptual point when a retrieved file can start to behave
as "normal". So take an extra reference on the folios and freeze the
memfd on retrieve until finish.

Suggested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
---
 mm/memfd_luo.c | 87 +++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 68 insertions(+), 19 deletions(-)

diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
index 9fd9abf9fedf6..50dbbda47ad3c 100644
--- a/mm/memfd_luo.c
+++ b/mm/memfd_luo.c
@@ -55,6 +55,14 @@
  *   Only seals known to this LUO version (see ``MEMFD_LUO_ALL_SEALS``) may
  *   be present; preservation fails with ``-EOPNOTSUPP`` otherwise.
  *
+ * Restrictions
+ * ============
+ *
+ * While a memfd is preserved, and after it is retrieved until the session is
+ * finished, its size can't be changed and holes can't be punched in it.
+ * Operations that would do so (``ftruncate()``, ``fallocate()``, writes past
+ * the end of the file) fail.
+ *
  * Non-Preserved Properties
  * ========================
  *
@@ -456,33 +464,56 @@ static void memfd_luo_discard_folios(const struct memfd_luo_folio_ser *folios_se
 	}
 }
 
+/* Drop the references retrieve() holds on the folios added to the file. */
+static void
+memfd_luo_put_retrieved_folios(const struct memfd_luo_folio_ser *folios_ser,
+			       u64 nr_folios)
+{
+	for (u64 i = 0; i < nr_folios; i++) {
+		const struct memfd_luo_folio_ser *pfolio = &folios_ser[i];
+
+		if (pfolio->pfn)
+			folio_put(pfn_folio(pfolio->pfn));
+	}
+}
+
 static void memfd_luo_finish(struct liveupdate_file_op_args *args)
 {
 	struct memfd_luo_folio_ser *folios_ser;
 	struct memfd_luo_ser *ser;
 
-	/*
-	 * If retrieve was successful, nothing to do. If it failed, retrieve()
-	 * already cleaned up everything it could. So nothing to do there
-	 * either. Only need to clean up when retrieve was not called.
-	 */
-	if (args->retrieve_status)
+	/* If retrieve failed, it already cleaned up everything it could. */
+	if (args->retrieve_status < 0)
 		return;
 
 	ser = phys_to_virt(args->serialized_data);
 	if (!ser)
 		return;
 
-	if (ser->nr_folios) {
-		folios_ser = kho_restore_vmalloc(&ser->folios);
-		if (!folios_ser)
-			goto out;
+	if (args->retrieve_status > 0) {
+		/*
+		 * Retrieve was successful, release the folios and unfreeze the
+		 * file so it can be used normally.
+		 */
+		struct inode *inode = file_inode(args->file);
+
+		folios_ser = args->private_data;
+
+		inode_lock(inode);
+		memfd_luo_put_retrieved_folios(folios_ser, ser->nr_folios);
+		shmem_freeze(inode, false);
+		inode_unlock(inode);
 
-		memfd_luo_discard_folios(folios_ser, ser->nr_folios);
 		vfree(folios_ser);
+	} else if (args->retrieve_status == 0 && ser->nr_folios) {
+		/* Retrieve was not called, discard the preserved folios. */
+		folios_ser = kho_restore_vmalloc(&ser->folios);
+		if (folios_ser) {
+			memfd_luo_discard_folios(folios_ser, ser->nr_folios);
+			vfree(folios_ser);
+		}
 	}
 
-out:
 	kho_restore_free(ser);
 }
 
@@ -552,7 +583,10 @@ static int memfd_luo_retrieve_folios(struct file *file,
 		nr_added_pages += npages;
 		folio_add_lru(folio);
 		folio_unlock(folio);
-		folio_put(folio);
+		/*
+		 * Keep the reference from kho_restore_folio(). It is dropped
+		 * in finish().
+		 */
 	}
 
 	shmem_recalc_inode(inode, nr_added_pages, 0);
@@ -566,9 +600,12 @@ static int memfd_luo_retrieve_folios(struct file *file,
 	folio_put(folio);
 put_folios:
 	/*
-	 * Note: don't free the folios already added to the file. They will be
-	 * freed when the file is freed. Free the ones not added yet here.
+	 * Drop the references held on the folios already added to the file.
+	 * The folios themselves will be freed when the file is freed.
 	 */
+	memfd_luo_put_retrieved_folios(folios_ser, i);
+
+	/* Free the ones not added yet here. */
 	for (long j = i + 1; j < nr_folios; j++) {
 		const struct memfd_luo_folio_ser *pfolio = &folios_ser[j];
 		phys_addr_t phys;
@@ -589,7 +626,7 @@ static int memfd_luo_retrieve_folios(struct file *file,
 
 static int memfd_luo_retrieve(struct liveupdate_file_op_args *args)
 {
-	struct memfd_luo_folio_ser *folios_ser;
+	struct memfd_luo_folio_ser *folios_ser = NULL;
 	struct memfd_luo_ser *ser;
 	struct file *file;
 	int err;
@@ -624,6 +661,17 @@ static int memfd_luo_retrieve(struct liveupdate_file_op_args *args)
 	vfs_setpos(file, ser->pos, MAX_LFS_FILESIZE);
 	i_size_write(file_inode(file), ser->size);
 
+	/*
+	 * Keep the file frozen until finish(). Other preserved objects might
+	 * depend on it.
+	 *
+	 * The file isn't visible to anyone yet, but take the lock anyway since
+	 * shmem_freeze() requires it.
+	 */
+	inode_lock(file_inode(file));
+	shmem_freeze(file_inode(file), true);
+	inode_unlock(file_inode(file));
+
 	if (ser->nr_folios) {
 		folios_ser = kho_restore_vmalloc(&ser->folios);
 		if (!folios_ser) {
@@ -632,16 +680,17 @@ static int memfd_luo_retrieve(struct liveupdate_file_op_args *args)
 		}
 
 		err = memfd_luo_retrieve_folios(file, folios_ser, ser->nr_folios);
-		vfree(folios_ser);
 		if (err)
-			goto put_file;
+			goto free_folios_ser;
 	}
 
 	args->file = file;
-	kho_restore_free(ser);
+	args->private_data = folios_ser;
 
 	return 0;
 
+free_folios_ser:
+	vfree(folios_ser);
 put_file:
 	fput(file);
 free_ser:
-- 
2.56.0.385.gac671c819a-goog


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 2/2] mm/memfd_luo: keep memfd frozen until finish
  2026-11-03 18:19 ` [PATCH 2/2] mm/memfd_luo: keep memfd frozen " Pratyush Yadav
@ 2026-11-03 20:35   ` Pasha Tatashin
  0 siblings, 0 replies; 5+ messages in thread
From: Pasha Tatashin @ 2026-11-03 20:35 UTC (permalink / raw)
  To: Pratyush Yadav
  Cc: Pasha Tatashin, Mike Rapoport, Andrew Morton, Samiullah Khawaja,
	kexec, linux-kernel, linux-mm

> After a memfd is retrieved, it immediately goes back into "normal"
> operation. The file comes back unfrozen, and its pages can migrate, it
> can be truncated, and so on. If the memfd is depended on by something,
> like iommufd, that can open a window for folios to move around before
> the consumer can re-establish its references.
> 
> Finish is the conceptual point when a retrieved file can start to behave
> as "normal". So take an extra reference on the folios and freeze the
> memfd on retrieve until finish.
> 
> Suggested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> Link: https://patch.msgid.link/20261103181916.2462825-3-pratyush@kernel.org
>
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> index 6b68220275eb..5abb9c0956af 100644
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
> @@ -55,6 +55,14 @@
>   *   Only seals known to this LUO version (see ``MEMFD_LUO_ALL_SEALS``) may
>   *   be present; preservation fails with ``-EOPNOTSUPP`` otherwise.
>   *
> + * Restrictions
> + * ============
> + *
> + * While a memfd is preserved, and after it is retrieved until the session is
> + * finished, its size can't be changed and holes can't be punched in it.
> + * Operations that would do so (``ftruncate()``, ``fallocate()``, writes past
> + * the end of the file) fail.
> + *
>   * Non-Preserved Properties
>   * ========================
>   *
> @@ -383,33 +391,56 @@ static void memfd_luo_discard_folios(const struct memfd_luo_folio_ser *folios_se
>  	}
>  }
>  
> +/* Drop the references retrieve() holds on the folios added to the file. */
> +static void
> +memfd_luo_put_retrieved_folios(const struct memfd_luo_folio_ser *folios_ser,
> +			       u64 nr_folios)
> +{
> +	for (u64 i = 0; i < nr_folios; i++) {
> +		const struct memfd_luo_folio_ser *pfolio = &folios_ser[i];
> +
> +		if (pfolio->pfn)
> +			folio_put(pfn_folio(pfolio->pfn));
> +	}
> +}
> +
>  static void memfd_luo_finish(struct liveupdate_file_op_args *args)
>  {
>  	struct memfd_luo_folio_ser *folios_ser;
>  	struct memfd_luo_ser *ser;
>  
> -	/*
> -	 * If retrieve was successful, nothing to do. If it failed, retrieve()
> -	 * already cleaned up everything it could. So nothing to do there
> -	 * either. Only need to clean up when retrieve was not called.
> -	 */
> -	if (args->retrieve_status)
> +	/* If retrieve failed, it already cleaned up everything it could. */
> +	if (args->retrieve_status < 0)
>  		return;
>  
>  	ser = phys_to_virt(args->serialized_data);
>  	if (!ser)
>  		return;
>  
> -	if (ser->nr_folios) {
> -		folios_ser = kho_restore_vmalloc(&ser->folios);
> -		if (!folios_ser)
> -			goto out;
> +	if (args->retrieve_status > 0) {
> +		/*
> +		 * Retrieve was successful, release the folios and unfreeze the
> +		 * file so it can be used normally.
> +		 */
> +		struct inode *inode = file_inode(args->file);
> +
> +		folios_ser = args->private_data;
> +
> +		inode_lock(inode);
> +		memfd_luo_put_retrieved_folios(folios_ser, ser->nr_folios);
> +		shmem_freeze(inode, false);
> +		inode_unlock(inode);
>  
> -		memfd_luo_discard_folios(folios_ser, ser->nr_folios);
>  		vfree(folios_ser);
> +	} else if (args->retrieve_status == 0 && ser->nr_folios) {
> +		/* Retrieve was not called, discard the preserved folios. */
> +		folios_ser = kho_restore_vmalloc(&ser->folios);
> +		if (folios_ser) {
> +			memfd_luo_discard_folios(folios_ser, ser->nr_folios);
> +			vfree(folios_ser);
> +		}

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> 

Side note (pre-existing, not an issue with this patch):

Initially, I wondered whether we should disallow auto-finishing an 
unretrieved memfd, in case a preserved device still had this memory 
mapped for DMA. However, if we reach this point, can_finish() has 
already passed for every other FD in this session, which means any 
possibly dependent FDs (e.g. iommufd/vfio) have already determined that 
this FD was not needed to be retrieved for their states.

-- 
Pasha


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve until finish
  2026-11-03 18:19 ` [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve " Pratyush Yadav
@ 2026-11-03 20:35   ` Pasha Tatashin
  0 siblings, 0 replies; 5+ messages in thread
From: Pasha Tatashin @ 2026-11-03 20:35 UTC (permalink / raw)
  To: Pratyush Yadav
  Cc: Pasha Tatashin, Mike Rapoport, Andrew Morton, Samiullah Khawaja,
	kexec, linux-kernel, linux-mm

> The private_data field of struct liveupdate_file_op_args lets file
> handlers keep runtime state that is not preserved. It is set by
> .preserve() and passed to the later outgoing callbacks, up to
> .unpreserve(). But in the new kernel, nothing set by .retrieve() is
> kept, and .can_finish() and .finish() always get a NULL private_data.
> 
> Handlers might need to keep runtime state from retrieve until finish.
> For example, memfd will need to remember the folios it holds on to
> until finish so it can release them there.
> 
> Save the private_data set by a successful .retrieve() in the luo_file,
> and pass it to .can_finish() and .finish(). The handler must free it in
> .finish().
> 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> Link: https://patch.msgid.link/20261103181916.2462825-2-pratyush@kernel.org
>
> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
> index 63ea5417de84..21caff8a98a7 100644
> --- a/include/linux/liveupdate.h
> +++ b/include/linux/liveupdate.h
> @@ -36,9 +36,11 @@ struct file;
>   * @serialized_data:  The opaque u64 handle, preserve/prepare/freeze may update
>   *                    this field.
>   * @private_data:     Private data for the file used to hold runtime state that
> - *                    is not preserved. Set by the handler's .preserve()
> - *                    callback, and must be freed in the handler's
> - *                    .unpreserve() callback.
> + *                    is not preserved. For outgoing, set by the handler's
> + *                    .preserve() callback, and must be freed in the handler's
> + *                    .unpreserve() callback. For incoming, set by the handler's
> + *                    .retrieve() callback on success, and must be freed in the
> + *                    handler's .finish() callback.
>   *
>   * This structure bundles all parameters for the file operation callbacks.
>   * The 'data' and 'file' fields are used for both input and output.

Please also update the stale: 'data' argument here.

With that,

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>

-- 
Pasha


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-11-03 20:35 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-03 18:19 [PATCH 0/2] memfd_luo: keep memfd frozen until finish Pratyush Yadav
2026-11-03 18:19 ` [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve " Pratyush Yadav
2026-11-03 20:35   ` Pasha Tatashin
2026-11-03 18:19 ` [PATCH 2/2] mm/memfd_luo: keep memfd frozen " Pratyush Yadav
2026-11-03 20:35   ` Pasha Tatashin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®