All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: pratyush@kernel.org, jasonmiu@google.com, graf@amazon.com,
	dmatlack@google.com, rientjes@google.com, corbet@lwn.net,
	rdunlap@infradead.org, ilpo.jarvinen@linux.intel.com,
	kanie@linux.alibaba.com, ojeda@kernel.org, aliceryhl@google.com,
	masahiroy@kernel.org, akpm@linux-foundation.org, tj@kernel.org,
	yoann.congal@smile.fr, mmaurer@google.com,
	roman.gushchin@linux.dev, chenridong@huawei.com, axboe@kernel.dk,
	mark.rutland@arm.com, jannh@google.com,
	vincent.guittot@linaro.org, hannes@cmpxchg.org,
	dan.j.williams@intel.com, david@redhat.com,
	joel.granados@kernel.org, rostedt@goodmis.org,
	anna.schumaker@oracle.com, song@kernel.org, linux@weissschuh.net,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-mm@kvack.org, gregkh@linuxfoundation.org,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	rafael@kernel.org, dakr@kernel.org,
	bartosz.golaszewski@linaro.org, cw00.choi@samsung.com,
	myungjoo.ham@samsung.com, yesanishhere@gmail.com,
	Jonathan.Cameron@huawei.com, quic_zijuhu@quicinc.com,
	aleksander.lobakin@intel.com, ira.weiny@intel.com,
	andriy.shevchenko@linux.intel.com, leon@kernel.org,
	lukas@wunner.de, bhelgaas@google.com, wagi@kernel.org,
	djeffery@redhat.com, stuart.w.hayes@gmail.com, ptyadav@amazon.de,
	lennart@poettering.net, brauner@kernel.org,
	linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	saeedm@nvidia.com, ajayachandra@nvidia.com, jgg@nvidia.com,
	parav@nvidia.com, leonro@nvidia.com, witu@nvidia.com,
	hughd@google.com, skhawaja@google.com, chrisl@kernel.org
Subject: Re: [PATCH v6 08/20] liveupdate: luo_flb: Introduce File-Lifecycle-Bound global state
Date: Mon, 17 Nov 2025 11:39:17 +0200	[thread overview]
Message-ID: <aRrtRfJaaIHw5DZN@kernel.org> (raw)
In-Reply-To: <20251115233409.768044-9-pasha.tatashin@soleen.com>

On Sat, Nov 15, 2025 at 06:33:54PM -0500, Pasha Tatashin wrote:
> Introduce a mechanism for managing global kernel state whose lifecycle
> is tied to the preservation of one or more files. This is necessary for
> subsystems where multiple preserved file descriptors depend on a single,
> shared underlying resource.
> 
> An example is HugeTLB, where multiple file descriptors such as memfd and
> guest_memfd may rely on the state of a single HugeTLB subsystem.
> Preserving this state for each individual file would be redundant and
> incorrect. The state should be preserved only once when the first file
> is preserved, and restored/finished only once the last file is handled.
> 
> This patch introduces File-Lifecycle-Bound (FLB) objects to solve this
> problem. An FLB is a global, reference-counted object with a defined set
> of operations:
> 
> - A file handler (struct liveupdate_file_handler) declares a dependency
>   on one or more FLBs via a new registration function,
>   liveupdate_register_flb().
> - When the first file depending on an FLB is preserved, the FLB's
>   .preserve() callback is invoked to save the shared global state. The
>   reference count is then incremented for each subsequent file.
> - Conversely, when the last file is unpreserved (before reboot) or
>   finished (after reboot), the FLB's .unpreserve() or .finish() callback
>   is invoked to clean up the global resource.
> 
> The implementation includes:
> 
> - A new set of ABI definitions (luo_flb_ser, luo_flb_head_ser) and a
>   corresponding FDT node (luo-flb) to serialize the state of all active
>   FLBs and pass them via Kexec Handover.
> - Core logic in luo_flb.c to manage FLB registration, reference
>   counting, and the invocation of lifecycle callbacks.
> - An API (liveupdate_flb_*_locked/*_unlock) for other kernel subsystems
>   to safely access the live object managed by an FLB, both before and
>   after the live update.
> 
> This framework provides the necessary infrastructure for more complex
> subsystems like IOMMU, VFIO, and KVM to integrate with the Live Update
> Orchestrator.

The concept makes sense to me, but it's hard to review the implementation
without an actual user.
 
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
>  include/linux/liveupdate.h         | 116 +++++
>  include/linux/liveupdate/abi/luo.h |  76 ++++
>  kernel/liveupdate/Makefile         |   1 +
>  kernel/liveupdate/luo_core.c       |   7 +-
>  kernel/liveupdate/luo_file.c       |   8 +
>  kernel/liveupdate/luo_flb.c        | 658 +++++++++++++++++++++++++++++
>  kernel/liveupdate/luo_internal.h   |   7 +
>  7 files changed, 872 insertions(+), 1 deletion(-)
>  create mode 100644 kernel/liveupdate/luo_flb.c
> 
> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
> index 4a5d4dd9905a..36a831ae3ead 100644
> --- a/include/linux/liveupdate.h
> +++ b/include/linux/liveupdate.h
> @@ -14,6 +14,7 @@
>  #include <uapi/linux/liveupdate.h>
>  
>  struct liveupdate_file_handler;
> +struct liveupdate_flb;
>  struct liveupdate_session;
>  struct file;
>  
> @@ -81,6 +82,7 @@ struct liveupdate_file_ops {
>   *                      associated with individual &struct file instances.
>   * @list:               Used for linking this handler instance into a global
>   *                      list of registered file handlers.
> + * @flb_list:           A list of FLB dependencies.
>   *
>   * Modules that want to support live update for specific file types should
>   * register an instance of this structure. LUO uses this registration to
> @@ -91,6 +93,80 @@ struct liveupdate_file_handler {
>  	const struct liveupdate_file_ops *ops;
>  	const char compatible[LIVEUPDATE_HNDL_COMPAT_LENGTH];
>  	struct list_head list;
> +	struct list_head flb_list;
> +};
> +
> +/**
> + * struct liveupdate_flb_op_args - Arguments for FLB operation callbacks.
> + * @flb:       The global FLB instance for which this call is performed.
> + * @data:      For .preserve():    [OUT] The callback sets this field.
> + *             For .unpreserve():  [IN]  The handle from .preserve().
> + *             For .retrieve():    [IN]  The handle from .preserve().
> + * @obj:       For .preserve():    [OUT] Sets this to the live object.
> + *             For .retrieve():    [OUT] Sets this to the live object.
> + *             For .finish():      [IN]  The live object from .retrieve().
> + *
> + * This structure bundles all parameters for the FLB operation callbacks.
> + */
> +struct liveupdate_flb_op_args {
> +	struct liveupdate_flb *flb;
> +	u64 data;
> +	void *obj;
> +};
> +
> +/**
> + * struct liveupdate_flb_ops - Callbacks for global File-Lifecycle-Bound data.
> + * @preserve:        Called when the first file using this FLB is preserved.
> + *                   The callback must save its state and return a single,
> + *                   self-contained u64 handle by setting the 'argp->data'
> + *                   field and 'argp->obj'.
> + * @unpreserve:      Called when the last file using this FLB is unpreserved
> + *                   (aborted before reboot). Receives the handle via
> + *                   'argp->data' and live object via 'argp->obj'.
> + * @retrieve:        Called on-demand in the new kernel, the first time a
> + *                   component requests access to the shared object. It receives
> + *                   the preserved handle via 'argp->data' and must reconstruct
> + *                   the live object, returning it by setting the 'argp->obj'
> + *                   field.
> + * @finish:          Called in the new kernel when the last file using this FLB
> + *                   is finished. Receives the live object via 'argp->obj' for
> + *                   cleanup.
> + * @owner:           Module reference
> + *
> + * Operations that manage global shared data with file bound lifecycle,
> + * triggered by the first file that uses it and concluded by the last file that
> + * uses it, across all sessions.
> + */
> +struct liveupdate_flb_ops {
> +	int (*preserve)(struct liveupdate_flb_op_args *argp);
> +	void (*unpreserve)(struct liveupdate_flb_op_args *argp);
> +	int (*retrieve)(struct liveupdate_flb_op_args *argp);
> +	void (*finish)(struct liveupdate_flb_op_args *argp);
> +	struct module *owner;
> +};
> +
> +/**
> + * struct liveupdate_flb - A global definition for a shared data object.
> + * @ops:         Callback functions
> + * @compatible:  The compatibility string (e.g., "iommu-core-v1"
> + *               that uniquely identifies the FLB type this handler
> + *               supports. This is matched against the compatible string
> + *               associated with individual &struct liveupdate_flb
> + *               instances.
> + * @list:        A global list of registered FLBs.
> + * @internal:    Internal state, set in liveupdate_init_flb().
> + *
> + * This struct is the "template" that a driver registers to define a shared,
> + * file-lifecycle-bound object. The actual runtime state (the live object,
> + * refcount, etc.) is managed internally by the LUO core.
> + * Use liveupdate_init_flb() to initialize this struct before using it in
> + * other functions.
> + */
> +struct liveupdate_flb {
> +	const struct liveupdate_flb_ops *ops;
> +	const char compatible[LIVEUPDATE_FLB_COMPAT_LENGTH];
> +	struct list_head list;
> +	void *internal;

Can't list be a part of internal?
And don't we usually call this .private rather than .internal?

>  };
>  
>  #ifdef CONFIG_LIVEUPDATE
> @@ -111,6 +187,17 @@ int liveupdate_get_file_incoming(struct liveupdate_session *s, u64 token,
>  int liveupdate_get_token_outgoing(struct liveupdate_session *s,
>  				  struct file *file, u64 *tokenp);
>  
> +/* Before using FLB for the first time it should be initialized */
> +int liveupdate_init_flb(struct liveupdate_flb *flb);
> +
> +int liveupdate_register_flb(struct liveupdate_file_handler *h,
> +			    struct liveupdate_flb *flb);

While these are obvious ...

> +
> +int liveupdate_flb_incoming_locked(struct liveupdate_flb *flb, void **objp);
> +void liveupdate_flb_incoming_unlock(struct liveupdate_flb *flb, void *obj);
> +int liveupdate_flb_outgoing_locked(struct liveupdate_flb *flb, void **objp);
> +void liveupdate_flb_outgoing_unlock(struct liveupdate_flb *flb, void *obj);
> +

... it's not very clear what these APIs are for and how they are going to be
used.

>  #else /* CONFIG_LIVEUPDATE */
  
...

> +int liveupdate_register_flb(struct liveupdate_file_handler *h,
> +			    struct liveupdate_flb *flb)
> +{
> +	struct luo_flb_internal *internal = flb->internal;
> +	struct luo_flb_link *link __free(kfree) = NULL;
> +	static DEFINE_MUTEX(register_flb_lock);
> +	struct liveupdate_flb *gflb;
> +	struct luo_flb_link *iter;
> +
> +	if (!liveupdate_enabled())
> +		return -EOPNOTSUPP;
> +
> +	if (WARN_ON(!h || !flb || !internal))
> +		return -EINVAL;
> +
> +	if (WARN_ON(!flb->ops->preserve || !flb->ops->unpreserve ||
> +		    !flb->ops->retrieve || !flb->ops->finish)) {
> +		return -EINVAL;
> +	}
> +
> +	/*
> +	 * Once session/files have been deserialized, FLBs cannot be registered,
> +	 * it is too late. Deserialization uses file handlers, and FLB registers
> +	 * to file handlers.
> +	 */
> +	if (WARN_ON(luo_session_is_deserialized()))
> +		return -EBUSY;
> +
> +	/*
> +	 * File handler must already be registered, as it is initializes the
> +	 * flb_list
> +	 */
> +	if (WARN_ON(list_empty(&h->list)))
> +		return -EINVAL;
> +
> +	link = kzalloc(sizeof(*link), GFP_KERNEL);
> +	if (!link)
> +		return -ENOMEM;
> +
> +	guard(mutex)(&register_flb_lock);
> +
> +	/* Check that this FLB is not already linked to this file handler */
> +	list_for_each_entry(iter, &h->flb_list, list) {
> +		if (iter->flb == flb)
> +			return -EEXIST;
> +	}
> +
> +	/* Is this FLB linked to global list ? */

Maybe:

	/*
	 * If this FLB is not linked to global list it's first time the FLB
	 * is registered
	 */

> +	if (list_empty(&flb->list)) {
> +		if (luo_flb_global.count == LUO_FLB_MAX)
> +			return -ENOSPC;
> +
> +		/* Check that compatible string is unique in global list */
> +		list_for_each_entry(gflb, &luo_flb_global.list, list) {
> +			if (!strcmp(gflb->compatible, flb->compatible))
> +				return -EEXIST;
> +		}
> +
> +		if (!try_module_get(flb->ops->owner))
> +			return -EAGAIN;
> +
> +		list_add_tail(&flb->list, &luo_flb_global.list);
> +		luo_flb_global.count++;
> +	}
> +
> +	/* Finally, link the FLB to the file handler */
> +	link->flb = flb;
> +	list_add_tail(&no_free_ptr(link)->list, &h->flb_list);
> +
> +	return 0;
> +}
> +
> +/**
> + * liveupdate_flb_incoming_locked - Lock and retrieve the incoming FLB object.
> + * @flb:  The FLB definition.
> + * @objp: Output parameter; will be populated with the live shared object.
> + *
> + * Acquires the FLB's internal lock and returns a pointer to its shared live
> + * object for the incoming (post-reboot) path.
> + *
> + * If this is the first time the object is requested in the new kernel, this
> + * function will trigger the FLB's .retrieve() callback to reconstruct the
> + * object from its preserved state. Subsequent calls will return the same
> + * cached object.
> + *
> + * The caller MUST call liveupdate_flb_incoming_unlock() to release the lock.
> + *
> + * Return: 0 on success, or a negative errno on failure. -ENODATA means no
> + * incoming FLB data, -ENOENT means specific flb not found in the incoming
> + * data, and -EOPNOTSUPP when live update is disabled or not configured.
> + */
> +int liveupdate_flb_incoming_locked(struct liveupdate_flb *flb, void **objp)
> +{
> +	struct luo_flb_internal *internal = flb->internal;
> +
> +	if (!liveupdate_enabled())
> +		return -EOPNOTSUPP;
> +
> +	if (WARN_ON(!internal))
> +		return -EINVAL;
> +
> +	if (!internal->incoming.obj) {
> +		int err = luo_flb_retrieve_one(flb);
> +
> +		if (err)
> +			return err;
> +	}
> +
> +	mutex_lock(&internal->incoming.lock);
> +	*objp = internal->incoming.obj;
> +
> +	return 0;
> +}
> +
> +/**
> + * liveupdate_flb_incoming_unlock - Unlock an incoming FLB object.
> + * @flb: The FLB definition.
> + * @obj: The object that was returned by the _locked call (used for validation).
> + *
> + * Releases the internal lock acquired by liveupdate_flb_incoming_locked().
> + */
> +void liveupdate_flb_incoming_unlock(struct liveupdate_flb *flb, void *obj)
> +{
> +	struct luo_flb_internal *internal = flb->internal;
> +
> +	lockdep_assert_held(&internal->incoming.lock);
> +	internal->incoming.obj = obj;

The comment says obj is for validation and here it's assigned to flb.
Something is off here :)

> +	mutex_unlock(&internal->incoming.lock);
> +}
> +
> +/**
> + * liveupdate_flb_outgoing_locked - Lock and retrieve the outgoing FLB object.
> + * @flb:  The FLB definition.
> + * @objp: Output parameter; will be populated with the live shared object.
> + *
> + * Acquires the FLB's internal lock and returns a pointer to its shared live
> + * object for the outgoing (pre-reboot) path.
> + *
> + * This function assumes the object has already been created by the FLB's
> + * .preserve() callback, which is triggered when the first dependent file
> + * is preserved.
> + *
> + * The caller MUST call liveupdate_flb_outgoing_unlock() to release the lock.
> + *
> + * Return: 0 on success, or a negative errno on failure.
> + */
> +int liveupdate_flb_outgoing_locked(struct liveupdate_flb *flb, void **objp)
> +{
> +	struct luo_flb_internal *internal = flb->internal;
> +
> +	if (!liveupdate_enabled())
> +		return -EOPNOTSUPP;
> +
> +	if (WARN_ON(!internal))
> +		return -EINVAL;
> +
> +	mutex_lock(&internal->outgoing.lock);
> +
> +	/* The object must exist if any file is being preserved */
> +	if (WARN_ON_ONCE(!internal->outgoing.obj)) {
> +		mutex_unlock(&internal->outgoing.lock);
> +		return -ENOENT;
> +	}

_incoming_locked() and outgoing_locked() are nearly identical, it seems we
can have the common part in a 
static liveupdate_flb_locked(struct luo_flb_state *state).

liveupdate_flb_incoming_locked() will be oneline wrapper and
liveupdate_flb_outgoing_locked() will have this WARN_ON if obj is NULL.

> +
> +	*objp = internal->outgoing.obj;
> +
> +	return 0;
> +}
> +
> +/**
> + * liveupdate_flb_outgoing_unlock - Unlock an outgoing FLB object.
> + * @flb: The FLB definition.
> + * @obj: The object that was returned by the _locked call (used for validation).
> + *
> + * Releases the internal lock acquired by liveupdate_flb_outgoing_locked().
> + */
> +void liveupdate_flb_outgoing_unlock(struct liveupdate_flb *flb, void *obj)
> +{
> +	struct luo_flb_internal *internal = flb->internal;
> +
> +	lockdep_assert_held(&internal->outgoing.lock);
> +	internal->outgoing.obj = obj;

So it is assignment or validation? ;-)

This one is a copy of liveupdate_flb_incoming_unlock(), 

> +	mutex_unlock(&internal->outgoing.lock);
> +}
> +

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2025-11-17  9:39 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-15 23:33 [PATCH v6 00/20] Live Update Orchestrator Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 01/20] liveupdate: luo_core: luo_ioctl: " Pasha Tatashin
2025-11-17  2:54   ` Andrew Morton
2025-11-17 14:27     ` Pasha Tatashin
2025-11-18 15:45   ` Pratyush Yadav
2025-11-18 16:11     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 02/20] liveupdate: luo_core: integrate with KHO Pasha Tatashin
2025-11-16 12:43   ` Mike Rapoport
2025-11-16 14:55     ` Pasha Tatashin
2025-11-16 19:16       ` Mike Rapoport
2025-11-17 18:29         ` Pasha Tatashin
2025-11-17 21:05           ` Mike Rapoport
2025-11-18  4:22             ` Pasha Tatashin
2025-11-18 11:21               ` Mike Rapoport
2025-11-18 14:03                 ` Jason Gunthorpe
2025-11-18 15:06                   ` Mike Rapoport
2025-11-18 15:18                     ` Pasha Tatashin
2025-11-18 15:36                       ` Jason Gunthorpe
2025-11-18 15:46                         ` Pasha Tatashin
2025-11-18 16:15                           ` Jason Gunthorpe
2025-11-18 22:07                             ` Pasha Tatashin
2025-11-18 23:25                               ` Jason Gunthorpe
2025-11-19  3:03                                 ` Pasha Tatashin
2025-11-24 19:08                                   ` Jason Gunthorpe
2025-11-15 23:33 ` [PATCH v6 03/20] kexec: call liveupdate_reboot() before kexec Pasha Tatashin
2025-11-16 12:44   ` Mike Rapoport
2025-11-21 15:55   ` Pratyush Yadav
2025-11-15 23:33 ` [PATCH v6 04/20] liveupdate: luo_session: add sessions support Pasha Tatashin
2025-11-16 17:05   ` Mike Rapoport
2025-11-17 15:09     ` Pasha Tatashin
2025-11-17 21:11       ` Mike Rapoport
2025-11-18  4:28         ` Pasha Tatashin
2025-11-21 16:32   ` Pratyush Yadav
2025-11-21 21:30     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 05/20] liveupdate: luo_ioctl: add user interface Pasha Tatashin
2025-11-16 17:15   ` Mike Rapoport
2025-11-17 14:22     ` Pasha Tatashin
2025-11-20 18:37   ` David Matlack
2025-11-20 19:22     ` Pasha Tatashin
2025-11-20 19:42       ` David Matlack
2025-11-20 20:13         ` Pasha Tatashin
2025-11-21 16:45   ` Pratyush Yadav
2025-11-15 23:33 ` [PATCH v6 06/20] liveupdate: luo_file: implement file systems callbacks Pasha Tatashin
2025-11-16 18:15   ` Mike Rapoport
2025-11-17 17:50     ` Pasha Tatashin
2025-11-20 17:20       ` Mike Rapoport
2025-11-20 20:25         ` Pasha Tatashin
2025-11-18 17:38   ` David Matlack
2025-11-18 17:43     ` Pratyush Yadav
2025-11-18 17:58       ` Pasha Tatashin
2025-11-18 18:17         ` Pratyush Yadav
2025-11-18 19:09         ` Jason Gunthorpe
2025-11-18 19:31           ` Pasha Tatashin
2025-11-21 17:24   ` Pratyush Yadav
2025-11-15 23:33 ` [PATCH v6 07/20] liveupdate: luo_session: Add ioctls for file preservation Pasha Tatashin
2025-11-16 18:25   ` Mike Rapoport
2025-11-18  2:58     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 08/20] liveupdate: luo_flb: Introduce File-Lifecycle-Bound global state Pasha Tatashin
2025-11-17  9:39   ` Mike Rapoport [this message]
2025-11-18  3:54     ` Pasha Tatashin
2025-11-18 11:28       ` Mike Rapoport
2025-11-18 15:37         ` Pasha Tatashin
2025-11-20 18:50           ` Mike Rapoport
2025-11-20 19:10             ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 09/20] docs: add luo documentation Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 10/20] MAINTAINERS: add liveupdate entry Pasha Tatashin
2025-11-17  9:40   ` Mike Rapoport
2025-11-17 18:20     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 11/20] mm: shmem: use SHMEM_F_* flags instead of VM_* flags Pasha Tatashin
2025-11-17  9:48   ` Mike Rapoport
2025-11-17 18:25     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 12/20] mm: shmem: allow freezing inode mapping Pasha Tatashin
2025-11-17 10:08   ` Mike Rapoport
2025-11-18  4:13     ` Pasha Tatashin
2025-11-24 15:06     ` Pratyush Yadav
2025-11-15 23:33 ` [PATCH v6 13/20] mm: shmem: export some functions to internal.h Pasha Tatashin
2025-11-17 10:14   ` Mike Rapoport
2025-11-17 18:43     ` Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 14/20] liveupdate: luo_file: add private argument to store runtime state Pasha Tatashin
2025-11-17 10:15   ` Mike Rapoport
2025-11-17 18:45     ` Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 15/20] mm: memfd_luo: allow preserving memfd Pasha Tatashin
2025-11-17 11:03   ` Mike Rapoport
2025-11-19 21:56     ` Pasha Tatashin
2025-11-20 15:34       ` Pratyush Yadav
2025-11-15 23:34 ` [PATCH v6 16/20] docs: add documentation for memfd preservation via LUO Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 17/20] selftests/liveupdate: Add userspace API selftests Pasha Tatashin
2025-11-17 19:38   ` David Matlack
2025-11-17 20:16     ` Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 18/20] selftests/liveupdate: Add kexec-based selftest for session lifecycle Pasha Tatashin
2025-11-16 18:53   ` Zhu Yanjun
2025-11-17 18:23     ` Pasha Tatashin
2025-11-17 19:27   ` David Matlack
2025-11-17 20:08     ` David Matlack
2025-11-17 21:06       ` David Matlack
2025-11-18  1:01         ` Pasha Tatashin
2025-11-18  0:06   ` David Matlack
2025-11-18  1:08     ` Pasha Tatashin
2025-11-19 21:20   ` David Matlack
2025-11-19 22:12     ` Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 19/20] selftests/liveupdate: Add kexec test for multiple and empty sessions Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 20/20] tests/liveupdate: Add in-kernel liveupdate test Pasha Tatashin
2025-11-17 11:13   ` Mike Rapoport
2025-11-17 19:00     ` Pasha Tatashin
2025-11-18 11:30       ` Mike Rapoport
2025-11-18 18:56         ` 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=aRrtRfJaaIHw5DZN@kernel.org \
    --to=rppt@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=ajayachandra@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=aliceryhl@google.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anna.schumaker@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=brauner@kernel.org \
    --cc=chenridong@huawei.com \
    --cc=chrisl@kernel.org \
    --cc=corbet@lwn.net \
    --cc=cw00.choi@samsung.com \
    --cc=dakr@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=djeffery@redhat.com \
    --cc=dmatlack@google.com \
    --cc=graf@amazon.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=ira.weiny@intel.com \
    --cc=jannh@google.com \
    --cc=jasonmiu@google.com \
    --cc=jgg@nvidia.com \
    --cc=joel.granados@kernel.org \
    --cc=kanie@linux.alibaba.com \
    --cc=lennart@poettering.net \
    --cc=leon@kernel.org \
    --cc=leonro@nvidia.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@weissschuh.net \
    --cc=lukas@wunner.de \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mmaurer@google.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=ojeda@kernel.org \
    --cc=parav@nvidia.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pratyush@kernel.org \
    --cc=ptyadav@amazon.de \
    --cc=quic_zijuhu@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=rostedt@goodmis.org \
    --cc=saeedm@nvidia.com \
    --cc=skhawaja@google.com \
    --cc=song@kernel.org \
    --cc=stuart.w.hayes@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=wagi@kernel.org \
    --cc=witu@nvidia.com \
    --cc=x86@kernel.org \
    --cc=yesanishhere@gmail.com \
    --cc=yoann.congal@smile.fr \
    /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.