From: Pranjal Shrivastava <praan@google.com>
To: Samiullah Khawaja <skhawaja@google.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Robin Murphy <robin.murphy@arm.com>,
Kevin Tian <kevin.tian@intel.com>,
Alex Williamson <alex@shazbot.org>, Shuah Khan <shuah@kernel.org>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Saeed Mahameed <saeedm@nvidia.com>,
Adithya Jayachandran <ajayachandra@nvidia.com>,
Parav Pandit <parav@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>, William Tu <witu@nvidia.com>,
Pratyush Yadav <pratyush@kernel.org>,
David Matlack <dmatlack@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Chris Li <chrisl@kernel.org>, Vipin Sharma <vipinsh@google.com>,
YiFei Zhu <zhuyifei@google.com>
Subject: Re: [PATCH 03/14] liveupdate: luo_file: Add internal APIs for file preservation
Date: Wed, 18 Mar 2026 10:00:57 +0000 [thread overview]
Message-ID: <abp32cJgCUEWK6u-@google.com> (raw)
In-Reply-To: <20260203220948.2176157-4-skhawaja@google.com>
On Tue, Feb 03, 2026 at 10:09:37PM +0000, Samiullah Khawaja wrote:
> From: Pasha Tatashin <pasha.tatashin@soleen.com>
>
> The core liveupdate mechanism allows userspace to preserve file
> descriptors. However, kernel subsystems often manage struct file
> objects directly and need to participate in the preservation process
> programmatically without relying solely on userspace interaction.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> include/linux/liveupdate.h | 21 ++++++++++
> kernel/liveupdate/luo_file.c | 71 ++++++++++++++++++++++++++++++++
> kernel/liveupdate/luo_internal.h | 16 +++++++
> 3 files changed, 108 insertions(+)
>
> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
> index fe82a6c3005f..8e47504ba01e 100644
> --- a/include/linux/liveupdate.h
> +++ b/include/linux/liveupdate.h
> @@ -23,6 +23,7 @@ struct file;
> /**
> * struct liveupdate_file_op_args - Arguments for file operation callbacks.
> * @handler: The file handler being called.
> + * @session: The session this file belongs to.
> * @retrieved: The retrieve status for the 'can_finish / finish'
> * operation.
> * @file: The file object. For retrieve: [OUT] The callback sets
> @@ -40,6 +41,7 @@ struct file;
> */
> struct liveupdate_file_op_args {
> struct liveupdate_file_handler *handler;
> + struct liveupdate_session *session;
> bool retrieved;
Nit: I don't think this is on the latest tree. I see `int retrieved` [1]
in the latest tree. I guess we'd need to rebase it on the latest?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/linux/liveupdate.h#n46
> struct file *file;
> u64 serialized_data;
> @@ -234,6 +236,13 @@ int liveupdate_unregister_flb(struct liveupdate_file_handler *fh,
>
> int liveupdate_flb_get_incoming(struct liveupdate_flb *flb, void **objp);
> int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb, void **objp);
> +/* kernel can internally retrieve files */
> +int liveupdate_get_file_incoming(struct liveupdate_session *s, u64 token,
> + struct file **filep);
> +
> +/* Get a token for an outgoing file, or -ENOENT if file is not preserved */
> +int liveupdate_get_token_outgoing(struct liveupdate_session *s,
> + struct file *file, u64 *tokenp);
>
> #else /* CONFIG_LIVEUPDATE */
>
> @@ -281,5 +290,17 @@ static inline int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb,
> return -EOPNOTSUPP;
> }
>
> +static inline int liveupdate_get_file_incoming(struct liveupdate_session *s,
> + u64 token, struct file **filep)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int liveupdate_get_token_outgoing(struct liveupdate_session *s,
> + struct file *file, u64 *tokenp)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> #endif /* CONFIG_LIVEUPDATE */
> #endif /* _LINUX_LIVEUPDATE_H */
> diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c
> index 32759e846bc9..7ac591542059 100644
> --- a/kernel/liveupdate/luo_file.c
> +++ b/kernel/liveupdate/luo_file.c
> @@ -302,6 +302,7 @@ int luo_preserve_file(struct luo_file_set *file_set, u64 token, int fd)
> mutex_init(&luo_file->mutex);
>
> args.handler = fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = file;
> err = fh->ops->preserve(&args);
> if (err)
> @@ -355,6 +356,7 @@ void luo_file_unpreserve_files(struct luo_file_set *file_set)
> struct luo_file, list);
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.private_data = luo_file->private_data;
> @@ -383,6 +385,7 @@ static int luo_file_freeze_one(struct luo_file_set *file_set,
> struct liveupdate_file_op_args args = {0};
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.private_data = luo_file->private_data;
> @@ -404,6 +407,7 @@ static void luo_file_unfreeze_one(struct luo_file_set *file_set,
> struct liveupdate_file_op_args args = {0};
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.private_data = luo_file->private_data;
> @@ -590,6 +594,7 @@ int luo_retrieve_file(struct luo_file_set *file_set, u64 token,
> }
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.serialized_data = luo_file->serialized_data;
> err = luo_file->fh->ops->retrieve(&args);
> if (!err) {
> @@ -615,6 +620,7 @@ static int luo_file_can_finish_one(struct luo_file_set *file_set,
> struct liveupdate_file_op_args args = {0};
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.retrieved = luo_file->retrieved;
> @@ -632,6 +638,7 @@ static void luo_file_finish_one(struct luo_file_set *file_set,
> guard(mutex)(&luo_file->mutex);
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.retrieved = luo_file->retrieved;
> @@ -919,3 +926,67 @@ int liveupdate_unregister_file_handler(struct liveupdate_file_handler *fh)
> return err;
> }
> EXPORT_SYMBOL_GPL(liveupdate_unregister_file_handler);
> +
> +/**
> + * liveupdate_get_token_outgoing - Get the token for a preserved file.
> + * @s: The outgoing liveupdate session.
> + * @file: The file object to search for.
> + * @tokenp: Output parameter for the found token.
> + *
> + * Searches the list of preserved files in an outgoing session for a matching
> + * file object. If found, the corresponding user-provided token is returned.
> + *
> + * This function is intended for in-kernel callers that need to correlate a
> + * file with its liveupdate token.
> + *
> + * Context: Can be called from any context that can acquire the session mutex.
> + * Return: 0 on success, -ENOENT if the file is not preserved in this session.
> + */
> +int liveupdate_get_token_outgoing(struct liveupdate_session *s,
> + struct file *file, u64 *tokenp)
> +{
> + struct luo_file_set *file_set = luo_file_set_from_session(s);
> + struct luo_file *luo_file;
> + int err = -ENOENT;
> +
> + list_for_each_entry(luo_file, &file_set->files_list, list) {
Shouldn't we hold a lock while traversing the file_set? Couldn't this
race with an unpreserve? If a concurrent unpreserve (writer) calls
list_del while this reader is mid-iteration, we'll likely follow a stale
pointer..
I noticed that luo_preserve_file / upreserve and retrieve also don't
take locks while manipulating / iterating over file_set->files_list..
Shouldn't we protect these with a lock? Otherwise, how do we avoid
races in situations like:
1. CPU 0 (reader) is iterating the list A->B->C ..
2. CPU 1 (writer) is handling an unpreserve which remove file B
Am I missing something? If we're expecting the callers to hold a lock,
we should have a lockdep_assert in these functions..
> + if (luo_file->file == file) {
> + if (tokenp)
> + *tokenp = luo_file->token;
> + err = 0;
> + break;
> + }
> + }
> +
> + return err;
> +}
> +
> +/**
> + * liveupdate_get_file_incoming - Retrieves a preserved file for in-kernel use.
> + * @s: The incoming liveupdate session (restored from the previous kernel).
> + * @token: The unique token identifying the file to retrieve.
> + * @filep: On success, this will be populated with a pointer to the retrieved
> + * 'struct file'.
> + *
> + * Provides a kernel-internal API for other subsystems to retrieve their
> + * preserved files after a live update. This function is a simple wrapper
> + * around luo_retrieve_file(), allowing callers to find a file by its token.
> + *
> + * The operation is idempotent; subsequent calls for the same token will return
> + * a pointer to the same 'struct file' object.
> + *
> + * The caller receives a new reference to the file and must call fput() when it
> + * is no longer needed. The file's lifetime is managed by LUO and any userspace
> + * file descriptors. If the caller needs to hold a reference to the file beyond
> + * the immediate scope, it must call get_file() itself.
> + *
I'm little confused here, we say the op is idempotent, but also mention
that the caller receives a new reference. I'm wondering of a situation
where a driver calls this multiple times, incrementing the refcount with
each call. Do we rely on flb_file_finish to drop all the refcounts?
We should clarify the lifecycle requirements here: is the driver
expected to call fput() for every single call to
liveupdate_get_file_incoming(), or is the flb_finish callback intended
to be a 'catch-all' that reaps these?
> + * Context: Can be called from any context in the new kernel that has a handle
> + * to a restored session.
> + * Return: 0 on success. Returns -ENOENT if no file with the matching token is
> + * found, or any other negative errno on failure.
> + */
> +int liveupdate_get_file_incoming(struct liveupdate_session *s, u64 token,
> + struct file **filep)
> +{
> + return luo_retrieve_file(luo_file_set_from_session(s), token, filep);
> +}
> diff --git a/kernel/liveupdate/luo_internal.h b/kernel/liveupdate/luo_internal.h
> index 8083d8739b09..a24933d24fd9 100644
> --- a/kernel/liveupdate/luo_internal.h
> +++ b/kernel/liveupdate/luo_internal.h
> @@ -77,6 +77,22 @@ struct luo_session {
> struct mutex mutex;
> };
>
> +static inline struct liveupdate_session *luo_session_from_file_set(struct luo_file_set *file_set)
> +{
> + struct luo_session *session;
> +
> + session = container_of(file_set, struct luo_session, file_set);
> +
> + return (struct liveupdate_session *)session;
> +}
> +
> +static inline struct luo_file_set *luo_file_set_from_session(struct liveupdate_session *s)
> +{
> + struct luo_session *session = (struct luo_session *)s;
> +
> + return &session->file_set;
> +}
> +
> int luo_session_create(const char *name, struct file **filep);
> int luo_session_retrieve(const char *name, struct file **filep);
> int __init luo_session_setup_outgoing(void *fdt);
> --
>
Thanks,
Praan
next prev parent reply other threads:[~2026-03-18 10:01 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 22:09 [PATCH 00/14] iommu: Add live update state preservation Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 01/14] iommu: Implement IOMMU LU FLB callbacks Samiullah Khawaja
2026-03-11 21:07 ` Pranjal Shrivastava
2026-03-12 16:43 ` Samiullah Khawaja
2026-03-12 23:43 ` Pranjal Shrivastava
2026-03-13 16:47 ` Samiullah Khawaja
2026-03-13 15:36 ` Pranjal Shrivastava
2026-03-13 16:58 ` Samiullah Khawaja
2026-04-10 13:51 ` Jason Gunthorpe
2026-04-13 6:41 ` Tian, Kevin
2026-03-16 22:54 ` Vipin Sharma
2026-03-17 1:06 ` Samiullah Khawaja
2026-03-23 23:27 ` Vipin Sharma
2026-02-03 22:09 ` [PATCH 02/14] iommu: Implement IOMMU core liveupdate skeleton Samiullah Khawaja
2026-03-12 23:10 ` Pranjal Shrivastava
2026-03-13 18:42 ` Samiullah Khawaja
2026-03-17 20:09 ` Pranjal Shrivastava
2026-03-17 20:13 ` Samiullah Khawaja
2026-03-17 20:23 ` Pranjal Shrivastava
2026-03-17 21:03 ` Vipin Sharma
2026-03-18 18:51 ` Pranjal Shrivastava
2026-03-18 17:49 ` Samiullah Khawaja
2026-03-17 19:58 ` Vipin Sharma
2026-03-17 20:33 ` Samiullah Khawaja
2026-03-24 19:06 ` Vipin Sharma
2026-03-24 19:45 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 03/14] liveupdate: luo_file: Add internal APIs for file preservation Samiullah Khawaja
2026-03-18 10:00 ` Pranjal Shrivastava [this message]
2026-03-18 16:54 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 04/14] iommu/pages: Add APIs to preserve/unpreserve/restore iommu pages Samiullah Khawaja
2026-03-03 16:42 ` Ankit Soni
2026-03-03 18:41 ` Samiullah Khawaja
2026-03-20 17:27 ` Pranjal Shrivastava
2026-03-20 18:12 ` Samiullah Khawaja
2026-04-10 14:13 ` Jason Gunthorpe
2026-04-10 22:13 ` Samiullah Khawaja
2026-03-17 20:59 ` Vipin Sharma
2026-03-20 9:28 ` Pranjal Shrivastava
2026-03-20 18:27 ` Samiullah Khawaja
2026-03-20 11:01 ` Pranjal Shrivastava
2026-03-20 18:56 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 05/14] iommupt: Implement preserve/unpreserve/restore callbacks Samiullah Khawaja
2026-03-20 21:57 ` Pranjal Shrivastava
2026-03-23 16:41 ` Samiullah Khawaja
2026-04-10 14:16 ` Jason Gunthorpe
2026-04-10 23:02 ` Samiullah Khawaja
2026-04-10 23:16 ` Jason Gunthorpe
2026-04-13 19:31 ` Samiullah Khawaja
2026-04-13 22:33 ` Jason Gunthorpe
2026-04-13 23:28 ` Samiullah Khawaja
2026-04-13 23:40 ` Jason Gunthorpe
2026-02-03 22:09 ` [PATCH 06/14] iommu/vt-d: Implement device and iommu preserve/unpreserve ops Samiullah Khawaja
2026-03-19 16:04 ` Vipin Sharma
2026-03-19 16:27 ` Samiullah Khawaja
2026-03-20 23:01 ` Pranjal Shrivastava
2026-03-21 13:27 ` Pranjal Shrivastava
2026-03-23 18:32 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 07/14] iommu/vt-d: Restore IOMMU state and reclaimed domain ids Samiullah Khawaja
2026-03-19 20:54 ` Vipin Sharma
2026-03-20 1:05 ` Samiullah Khawaja
2026-03-22 19:51 ` Pranjal Shrivastava
2026-03-23 19:33 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 08/14] iommu: Restore and reattach preserved domains to devices Samiullah Khawaja
2026-03-10 5:16 ` Ankit Soni
2026-03-10 21:47 ` Samiullah Khawaja
2026-03-22 21:59 ` Pranjal Shrivastava
2026-03-23 18:02 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 09/14] iommu/vt-d: preserve PASID table of preserved device Samiullah Khawaja
2026-03-23 18:19 ` Pranjal Shrivastava
2026-03-23 18:51 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 10/14] iommufd-lu: Implement ioctl to let userspace mark an HWPT to be preserved Samiullah Khawaja
2026-03-19 23:35 ` Vipin Sharma
2026-03-20 0:40 ` Samiullah Khawaja
2026-03-20 23:34 ` Vipin Sharma
2026-03-23 16:24 ` Samiullah Khawaja
2026-03-25 14:37 ` Pranjal Shrivastava
2026-03-25 17:31 ` Samiullah Khawaja
2026-03-25 18:55 ` Pranjal Shrivastava
2026-03-25 20:19 ` Samiullah Khawaja
2026-03-25 20:36 ` Pranjal Shrivastava
2026-03-25 20:46 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 11/14] iommufd-lu: Persist iommu hardware pagetables for live update Samiullah Khawaja
2026-02-25 23:47 ` Samiullah Khawaja
2026-03-03 5:56 ` Ankit Soni
2026-03-03 18:51 ` Samiullah Khawaja
2026-03-23 20:28 ` Vipin Sharma
2026-03-23 21:34 ` Samiullah Khawaja
2026-03-25 20:08 ` Pranjal Shrivastava
2026-03-25 20:32 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 12/14] iommufd: Add APIs to preserve/unpreserve a vfio cdev Samiullah Khawaja
2026-03-23 20:59 ` Vipin Sharma
2026-03-23 21:38 ` Samiullah Khawaja
2026-03-25 20:24 ` Pranjal Shrivastava
2026-03-25 20:41 ` Samiullah Khawaja
2026-03-25 21:23 ` Pranjal Shrivastava
2026-03-26 0:16 ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 13/14] vfio/pci: Preserve the iommufd state of the " Samiullah Khawaja
2026-02-17 4:18 ` Ankit Soni
2026-03-03 18:35 ` Samiullah Khawaja
2026-03-23 21:17 ` Vipin Sharma
2026-03-23 22:07 ` Samiullah Khawaja
2026-03-24 20:30 ` Vipin Sharma
2026-03-25 20:55 ` Pranjal Shrivastava
2026-02-03 22:09 ` [PATCH 14/14] iommufd/selftest: Add test to verify iommufd preservation Samiullah Khawaja
2026-03-23 22:18 ` Vipin Sharma
2026-03-27 18:32 ` Samiullah Khawaja
2026-03-25 21:05 ` Pranjal Shrivastava
2026-03-27 18:25 ` Samiullah Khawaja
2026-03-27 18:40 ` Samiullah Khawaja
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=abp32cJgCUEWK6u-@google.com \
--to=praan@google.com \
--cc=ajayachandra@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=alex@shazbot.org \
--cc=baolu.lu@linux.intel.com \
--cc=chrisl@kernel.org \
--cc=dmatlack@google.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=parav@nvidia.com \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=robin.murphy@arm.com \
--cc=saeedm@nvidia.com \
--cc=shuah@kernel.org \
--cc=skhawaja@google.com \
--cc=vipinsh@google.com \
--cc=will@kernel.org \
--cc=witu@nvidia.com \
--cc=zhuyifei@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.