From: Mike Rapoport <rppt@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: pratyush@kernel.org, jasonmiu@google.com, graf@amazon.com,
changyuanl@google.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,
zhangguopeng@kylinos.cn, 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
Subject: Re: [RFC v2 08/16] luo: luo_files: add infrastructure for FDs
Date: Mon, 26 May 2025 10:55:05 +0300 [thread overview]
Message-ID: <aDQeWT9sLNQVZKf-@kernel.org> (raw)
In-Reply-To: <20250515182322.117840-9-pasha.tatashin@soleen.com>
On Thu, May 15, 2025 at 06:23:12PM +0000, Pasha Tatashin wrote:
> Introduce the framework within LUO to support preserving specific types
> of file descriptors across a live update transition. This allows
> stateful FDs (like memfds or vfio FDs used by VMs) to be recreated in
> the new kernel.
>
> Note: The core logic for iterating through the luo_files_list and
> invoking the handler callbacks (prepare, freeze, cancel, finish)
> within luo_do_files_*_calls, as well as managing the u64 data
> persistence via the FDT for individual files, is currently implemented
> as stubs in this patch. This patch sets up the registration, FDT layout,
> and retrieval framework.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> drivers/misc/liveupdate/Makefile | 1 +
> drivers/misc/liveupdate/luo_core.c | 19 +
> drivers/misc/liveupdate/luo_files.c | 563 +++++++++++++++++++++++++
> drivers/misc/liveupdate/luo_internal.h | 11 +
> include/linux/liveupdate.h | 62 +++
> 5 files changed, 656 insertions(+)
> create mode 100644 drivers/misc/liveupdate/luo_files.c
>
> diff --git a/drivers/misc/liveupdate/Makefile b/drivers/misc/liveupdate/Makefile
> index df1c9709ba4f..b4cdd162574f 100644
> --- a/drivers/misc/liveupdate/Makefile
> +++ b/drivers/misc/liveupdate/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-y += luo_core.o
> +obj-y += luo_files.o
> obj-y += luo_subsystems.o
> diff --git a/drivers/misc/liveupdate/luo_core.c b/drivers/misc/liveupdate/luo_core.c
> index 417e7f6bf36c..ab1d76221fe2 100644
> --- a/drivers/misc/liveupdate/luo_core.c
> +++ b/drivers/misc/liveupdate/luo_core.c
> @@ -110,6 +110,10 @@ static int luo_fdt_setup(struct kho_serialization *ser)
> if (ret)
> goto exit_free;
>
> + ret = luo_files_fdt_setup(fdt_out);
> + if (ret)
> + goto exit_free;
> +
> ret = luo_subsystems_fdt_setup(fdt_out);
> if (ret)
> goto exit_free;
The duplication of files and subsystems does not look nice here and below.
Can't we make files to be a subsystem?
> @@ -145,7 +149,13 @@ static int luo_do_prepare_calls(void)
> {
> int ret;
>
> + ret = luo_do_files_prepare_calls();
> + if (ret)
> + return ret;
> +
> ret = luo_do_subsystems_prepare_calls();
> + if (ret)
> + luo_do_files_cancel_calls();
>
> return ret;
> }
> @@ -154,18 +164,26 @@ static int luo_do_freeze_calls(void)
> {
> int ret;
>
> + ret = luo_do_files_freeze_calls();
> + if (ret)
> + return ret;
> +
> ret = luo_do_subsystems_freeze_calls();
> + if (ret)
> + luo_do_files_cancel_calls();
>
> return ret;
> }
>
> static void luo_do_finish_calls(void)
> {
> + luo_do_files_finish_calls();
> luo_do_subsystems_finish_calls();
> }
>
> static void luo_do_cancel_calls(void)
> {
> + luo_do_files_cancel_calls();
> luo_do_subsystems_cancel_calls();
> }
>
> @@ -436,6 +454,7 @@ static int __init luo_startup(void)
> }
>
> __luo_set_state(LIVEUPDATE_STATE_UPDATED);
> + luo_files_startup(luo_fdt_in);
> luo_subsystems_startup(luo_fdt_in);
>
> return 0;
> diff --git a/drivers/misc/liveupdate/luo_files.c b/drivers/misc/liveupdate/luo_files.c
> new file mode 100644
> index 000000000000..953fc40db3d7
> --- /dev/null
> +++ b/drivers/misc/liveupdate/luo_files.c
> @@ -0,0 +1,563 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Copyright (c) 2025, Google LLC.
> + * Pasha Tatashin <pasha.tatashin@soleen.com>
> + */
> +
> +/**
> + * DOC: LUO file descriptors
> + *
> + * LUO provides the infrastructure necessary to preserve
> + * specific types of stateful file descriptors across a kernel live
> + * update transition. The primary goal is to allow workloads, such as virtual
> + * machines using vfio, memfd, or iommufd to retain access to their essential
> + * resources without interruption after the underlying kernel is updated.
> + *
> + * The framework operates based on handler registration and instance tracking:
> + *
> + * 1. Handler Registration: Kernel modules responsible for specific file
> + * types (e.g., memfd, vfio) register a &struct liveupdate_filesystem
> + * handler. This handler contains callbacks (&liveupdate_filesystem.prepare,
> + * &liveupdate_filesystem.freeze, &liveupdate_filesystem.finish, etc.)
> + * and a unique 'compatible' string identifying the file type.
> + * Registration occurs via liveupdate_register_filesystem().
I wouldn't use filesystem here, as the obvious users are not really
filesystems. Maybe liveupdate_register_file_ops?
> + *
> + * 2. File Instance Tracking: When a potentially preservable file needs to be
> + * managed for live update, the core LUO logic (luo_register_file()) finds a
> + * compatible registered handler using its &liveupdate_filesystem.can_preserve
> + * callback. If found, an internal &struct luo_file instance is created,
> + * assigned a unique u64 'token', and added to a list.
> + *
> + * 3. State Persistence (FDT): During the LUO prepare/freeze phases, the
> + * registered handler callbacks are invoked for each tracked file instance.
> + * These callbacks can generate a u64 data payload representing the minimal
> + * state needed for restoration. This payload, along with the handler's
> + * compatible string and the unique token, is stored in a dedicated
> + * '/file-descriptors' node within the main LUO FDT blob passed via
> + * Kexec Handover (KHO).
> + *
> + * 4. Restoration: In the new kernel, the LUO framework parses the incoming
> + * FDT to reconstruct the list of &struct luo_file instances. When the
> + * original owner requests the file, luo_retrieve_file() uses the corresponding
> + * handler's &liveupdate_filesystem.retrieve callback, passing the persisted
> + * u64 data, to recreate or find the appropriate &struct file object.
> + */
The DOC is mostly about what luo_files does, we'd also need a description
of it's intended use, both internally in the kernel and by the userspace.
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
...
> +/**
> + * luo_register_file - Register a file descriptor for live update management.
> + * @tokenp: Return argument for the token value.
> + * @file: Pointer to the struct file to be preserved.
> + *
> + * Context: Must be called when LUO is in 'normal' state.
> + *
> + * Return: 0 on success. Negative errno on failure.
> + */
> +int luo_register_file(u64 *tokenp, struct file *file)
> +{
> + struct liveupdate_filesystem *fs;
> + bool found = false;
> + int ret = -ENOENT;
> + u64 token;
> +
> + luo_state_read_enter();
> + if (!liveupdate_state_normal() && !liveupdate_state_updated()) {
> + pr_warn("File can be registered only in normal or prepared state\n");
> + luo_state_read_exit();
> + return -EBUSY;
> + }
> +
> + down_read(&luo_filesystems_list_rwsem);
> + list_for_each_entry(fs, &luo_filesystems_list, list) {
> + if (fs->can_preserve(file, fs->arg)) {
> + found = true;
> + break;
> + }
> + }
> +
> + if (found) {
if (!found)
goto exit_unlock;
> + struct luo_file *luo_file = kmalloc(sizeof(*luo_file),
> + GFP_KERNEL);
> +
> + if (!luo_file) {
> + ret = -ENOMEM;
> + goto exit_unlock;
> + }
> +
> + token = luo_next_file_token;
> + luo_next_file_token++;
> +
> + luo_file->private_data = 0;
> + luo_file->reclaimed = false;
> +
> + luo_file->file = file;
> + luo_file->fs = fs;
> + mutex_init(&luo_file->mutex);
> + luo_file->state = LIVEUPDATE_STATE_NORMAL;
> + ret = xa_err(xa_store(&luo_files_xa_out, token, luo_file,
> + GFP_KERNEL));
> + if (ret < 0) {
> + pr_warn("Failed to store file for token %llu in XArray: %d\n",
> + token, ret);
> + kfree(luo_file);
> + goto exit_unlock;
> + }
> + *tokenp = token;
> + }
> +
> +exit_unlock:
> + up_read(&luo_filesystems_list_rwsem);
> + luo_state_read_exit();
> +
> + return ret;
> +}
> +
> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
> index 7a130680b5f2..7afe0aac5ce4 100644
> --- a/include/linux/liveupdate.h
> +++ b/include/linux/liveupdate.h
> @@ -86,6 +86,55 @@ enum liveupdate_state {
> LIVEUPDATE_STATE_UPDATED = 3,
> };
>
> +/* Forward declaration needed if definition isn't included */
> +struct file;
> +
> +/**
> + * struct liveupdate_filesystem - Represents a handler for a live-updatable
> + * filesystem/file type.
> + * @prepare: Optional. Saves state for a specific file instance (@file,
> + * @arg) before update, potentially returning value via @data.
> + * Returns 0 on success, negative errno on failure.
> + * @freeze: Optional. Performs final actions just before kernel
> + * transition, potentially reading/updating the handle via
> + * @data.
> + * Returns 0 on success, negative errno on failure.
> + * @cancel: Optional. Cleans up state/resources if update is aborted
> + * after prepare/freeze succeeded, using the @data handle (by
> + * value) from the successful prepare. Returns void.
> + * @finish: Optional. Performs final cleanup in the new kernel using the
> + * preserved @data handle (by value). Returns void.
> + * @retrieve: Retrieve the preserved file. Must be called before finish.
> + * @can_preserve: callback to determine if @file with associated context (@arg)
> + * can be preserved by this handler.
> + * Return bool (true if preservable, false otherwise).
> + * @compatible: The compatibility string (e.g., "memfd-v1", "vfiofd-v1")
> + * that uniquely identifies the filesystem or file type this
> + * handler supports. This is matched against the compatible
> + * string associated with individual &struct liveupdate_file
> + * instances.
> + * @arg: An opaque pointer to implementation-specific context data
> + * associated with this filesystem handler registration.
> + * @list: used for linking this handler instance into a global list of
> + * registered filesystem handlers.
> + *
> + * Modules that want to support live update for specific file types should
> + * register an instance of this structure. LUO uses this registration to
> + * determine if a given file can be preserved and to find the appropriate
> + * operations to manage its state across the update.
> + */
> +struct liveupdate_filesystem {
> + int (*prepare)(struct file *file, void *arg, u64 *data);
> + int (*freeze)(struct file *file, void *arg, u64 *data);
> + void (*cancel)(struct file *file, void *arg, u64 data);
> + void (*finish)(struct file *file, void *arg, u64 data, bool reclaimed);
> + int (*retrieve)(void *arg, u64 data, struct file **file);
> + bool (*can_preserve)(struct file *file, void *arg);
> + const char *compatible;
> + void *arg;
> + struct list_head list;
> +};
> +
Like with subsystems, I'd split ops and make the data part private to
luo_files.c
> /**
> * struct liveupdate_subsystem - Represents a subsystem participating in LUO
> * @prepare: Optional. Called during LUO prepare phase. Should perform
> @@ -142,6 +191,9 @@ int liveupdate_register_subsystem(struct liveupdate_subsystem *h);
> int liveupdate_unregister_subsystem(struct liveupdate_subsystem *h);
> int liveupdate_get_subsystem_data(struct liveupdate_subsystem *h, u64 *data);
>
> +int liveupdate_register_filesystem(struct liveupdate_filesystem *h);
> +int liveupdate_unregister_filesystem(struct liveupdate_filesystem *h);
int liveupdate_register_file_ops(name, ops, data, ret_token) ?
> +
> #else /* CONFIG_LIVEUPDATE */
>
> static inline int liveupdate_reboot(void)
> @@ -180,5 +232,15 @@ static inline int liveupdate_get_subsystem_data(struct liveupdate_subsystem *h,
> return -ENODATA;
> }
>
> +static inline int liveupdate_register_filesystem(struct liveupdate_filesystem *h)
> +{
> + return 0;
> +}
> +
> +static inline int liveupdate_unregister_filesystem(struct liveupdate_filesystem *h)
> +{
> + return 0;
> +}
> +
> #endif /* CONFIG_LIVEUPDATE */
> #endif /* _LINUX_LIVEUPDATE_H */
> --
> 2.49.0.1101.gccaa498523-goog
>
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-05-26 7:55 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-15 18:23 [RFC v2 00/16] Live Update Orchestrator Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 01/16] kho: make debugfs interface optional Pasha Tatashin
2025-06-04 16:03 ` Pratyush Yadav
2025-06-06 16:12 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 02/16] kho: allow to drive kho from within kernel Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 03/16] kho: add kho_unpreserve_folio/phys Pasha Tatashin
2025-06-04 15:00 ` Pratyush Yadav
2025-06-06 16:22 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 04/16] luo: luo_core: Live Update Orchestrator Pasha Tatashin
2025-05-26 6:31 ` Mike Rapoport
2025-05-30 5:00 ` Pasha Tatashin
2025-06-04 15:17 ` Pratyush Yadav
2025-06-07 17:11 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 05/16] luo: luo_core: integrate with KHO Pasha Tatashin
2025-05-26 7:18 ` Mike Rapoport
2025-06-07 17:50 ` Pasha Tatashin
2025-06-09 2:14 ` Pasha Tatashin
2025-06-04 16:00 ` Pratyush Yadav
2025-06-07 23:30 ` Pasha Tatashin
2025-06-13 14:58 ` Pratyush Yadav
2025-06-17 15:23 ` Jason Gunthorpe
2025-06-17 19:32 ` Pasha Tatashin
2025-06-18 13:11 ` Pratyush Yadav
2025-06-18 14:48 ` Pasha Tatashin
2025-06-18 16:40 ` Mike Rapoport
2025-06-18 17:00 ` Pasha Tatashin
2025-06-18 17:43 ` Pasha Tatashin
2025-06-19 12:00 ` Mike Rapoport
2025-06-19 14:22 ` Pasha Tatashin
2025-06-20 15:28 ` Pratyush Yadav
2025-06-20 16:03 ` Pasha Tatashin
2025-06-24 16:12 ` Pratyush Yadav
2025-06-24 16:55 ` Pasha Tatashin
2025-06-24 18:31 ` Jason Gunthorpe
2025-06-23 7:32 ` Mike Rapoport
2025-06-23 11:29 ` Pasha Tatashin
2025-06-25 13:46 ` Mike Rapoport
2025-05-15 18:23 ` [RFC v2 06/16] luo: luo_subsystems: add subsystem registration Pasha Tatashin
2025-05-26 7:31 ` Mike Rapoport
2025-06-07 23:42 ` Pasha Tatashin
2025-05-28 19:12 ` David Matlack
2025-06-07 23:58 ` Pasha Tatashin
2025-06-04 16:30 ` Pratyush Yadav
2025-06-08 0:04 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 07/16] luo: luo_subsystems: implement subsystem callbacks Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 08/16] luo: luo_files: add infrastructure for FDs Pasha Tatashin
2025-05-15 23:15 ` James Houghton
2025-05-23 18:09 ` Pasha Tatashin
2025-05-26 7:55 ` Mike Rapoport [this message]
2025-06-05 11:56 ` Pratyush Yadav
2025-06-08 13:13 ` Pasha Tatashin
2025-06-05 15:56 ` Pratyush Yadav
2025-06-08 13:37 ` Pasha Tatashin
2025-06-13 15:27 ` Pratyush Yadav
2025-06-15 18:02 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 09/16] luo: luo_files: implement file systems callbacks Pasha Tatashin
2025-06-05 16:03 ` Pratyush Yadav
2025-06-08 13:49 ` Pasha Tatashin
2025-06-13 15:18 ` Pratyush Yadav
2025-06-13 20:26 ` Pasha Tatashin
2025-06-16 10:43 ` Pratyush Yadav
2025-06-16 14:57 ` Pasha Tatashin
2025-06-18 13:16 ` Pratyush Yadav
2025-05-15 18:23 ` [RFC v2 10/16] luo: luo_ioctl: add ioctl interface Pasha Tatashin
2025-05-26 8:42 ` Mike Rapoport
2025-06-08 15:08 ` Pasha Tatashin
2025-05-28 20:29 ` David Matlack
2025-06-08 16:32 ` Pasha Tatashin
2025-06-05 16:15 ` Pratyush Yadav
2025-06-08 16:35 ` Pasha Tatashin
2025-06-24 9:50 ` Christian Brauner
2025-06-24 14:27 ` Pasha Tatashin
2025-06-25 9:36 ` Christian Brauner
2025-06-25 16:12 ` David Matlack
2025-06-26 15:42 ` Pratyush Yadav
2025-06-26 16:24 ` David Matlack
2025-07-14 14:56 ` Pratyush Yadav
2025-07-17 16:17 ` David Matlack
2025-07-23 14:51 ` Pratyush Yadav
2025-07-06 14:33 ` Mike Rapoport
2025-07-07 12:56 ` Jason Gunthorpe
2025-06-25 16:58 ` pasha.tatashin
2025-07-06 14:24 ` Mike Rapoport
2025-07-09 21:27 ` Pratyush Yadav
2025-07-10 7:26 ` Mike Rapoport
2025-07-14 14:34 ` Jason Gunthorpe
2025-07-16 9:43 ` Greg KH
2025-05-15 18:23 ` [RFC v2 11/16] luo: luo_sysfs: add sysfs state monitoring Pasha Tatashin
2025-06-05 16:20 ` Pratyush Yadav
2025-06-08 16:36 ` Pasha Tatashin
2025-06-13 15:13 ` Pratyush Yadav
2025-05-15 18:23 ` [RFC v2 12/16] reboot: call liveupdate_reboot() before kexec Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 13/16] luo: add selftests for subsystems un/registration Pasha Tatashin
2025-05-26 8:52 ` Mike Rapoport
2025-06-08 16:47 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 14/16] selftests/liveupdate: add subsystem/state tests Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 15/16] docs: add luo documentation Pasha Tatashin
2025-05-26 9:00 ` Mike Rapoport
2025-05-15 18:23 ` [RFC v2 16/16] MAINTAINERS: add liveupdate entry Pasha Tatashin
2025-05-20 7:25 ` [RFC v2 00/16] Live Update Orchestrator Mike Rapoport
2025-05-23 18:07 ` Pasha Tatashin
2025-05-26 6:32 ` Mike Rapoport
-- strict thread matches above, loose matches on Subject: below --
2025-06-06 22:28 [RFC v2 08/16] luo: luo_files: add infrastructure for FDs Anish Moorthy
2025-06-08 0:07 ` 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=aDQeWT9sLNQVZKf-@kernel.org \
--to=rppt@kernel.org \
--cc=Jonathan.Cameron@huawei.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=changyuanl@google.com \
--cc=chenridong@huawei.com \
--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=ilpo.jarvinen@linux.intel.com \
--cc=ira.weiny@intel.com \
--cc=jannh@google.com \
--cc=jasonmiu@google.com \
--cc=joel.granados@kernel.org \
--cc=kanie@linux.alibaba.com \
--cc=leon@kernel.org \
--cc=linux-doc@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=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=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=x86@kernel.org \
--cc=yesanishhere@gmail.com \
--cc=yoann.congal@smile.fr \
--cc=zhangguopeng@kylinos.cn \
/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.