From: Pratyush Yadav <pratyush@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>,
Mike Rapoport <rppt@kernel.org>,
Pratyush Yadav <pratyush@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Samiullah Khawaja <skhawaja@google.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve until finish
Date: Tue, 3 Nov 2026 19:19:13 +0100 [thread overview]
Message-ID: <20261103181916.2462825-2-pratyush@kernel.org> (raw)
In-Reply-To: <20261103181916.2462825-1-pratyush@kernel.org>
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
next prev parent reply other threads:[~2026-11-03 18:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 18:19 [PATCH 0/2] memfd_luo: keep memfd frozen " Pratyush Yadav
2026-11-03 18:19 ` Pratyush Yadav [this message]
2026-11-03 20:35 ` [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve " 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
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=20261103181916.2462825-2-pratyush@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@kernel.org \
--cc=skhawaja@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
all inboxes | Powered by JetHome®