From: Sebastian Ene <sebastianene@google.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: catalin.marinas@arm.com, gshan@redhat.com, james.morse@arm.com,
mark.rutland@arm.com, maz@kernel.org, rananta@google.com,
ricarkol@google.com, ryan.roberts@arm.com, shahuang@redhat.com,
suzuki.poulose@arm.com, will@kernel.org, yuzenghui@huawei.com,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel-team@android.com,
vdonnefort@google.com
Subject: Re: [PATCH v5 3/4] KVM: arm64: Register ptdump with debugfs on guest creation
Date: Tue, 13 Feb 2024 16:42:27 +0000 [thread overview]
Message-ID: <Zcub87FwaVPkCXQE@google.com> (raw)
In-Reply-To: <Zcq-NGa-Gd9rVVgF@linux.dev>
On Tue, Feb 13, 2024 at 12:56:20AM +0000, Oliver Upton wrote:
> On Wed, Feb 07, 2024 at 02:48:32PM +0000, Sebastian Ene wrote:
Hello Oliver,
> > While arch/*/mem/ptdump handles the kernel pagetable dumping code,
> > introduce KVM/ptdump which shows the guest stage-2 pagetables. The
> > separation is necessary because most of the definitions from the
> > stage-2 pagetable reside in the KVM path and we will be invoking
> > functionality **specific** to KVM.
> >
> > When a guest is created, register a new file entry under the guest
> > debugfs dir which allows userspace to show the contents of the guest
> > stage-2 pagetables when accessed.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/Kconfig | 13 ++++++
> > arch/arm64/kvm/Makefile | 1 +
> > arch/arm64/kvm/debug.c | 7 ++++
> > arch/arm64/kvm/kvm_ptdump.h | 20 ++++++++++
> > arch/arm64/kvm/ptdump.c | 79 +++++++++++++++++++++++++++++++++++++
> > 5 files changed, 120 insertions(+)
> > create mode 100644 arch/arm64/kvm/kvm_ptdump.h
> > create mode 100644 arch/arm64/kvm/ptdump.c
> >
> > diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> > index 6c3c8ca73e7f..28097dd72174 100644
> > --- a/arch/arm64/kvm/Kconfig
> > +++ b/arch/arm64/kvm/Kconfig
> > @@ -68,4 +68,17 @@ config PROTECTED_NVHE_STACKTRACE
> >
> > If unsure, or not using protected nVHE (pKVM), say N.
> >
> > +config PTDUMP_STAGE2_DEBUGFS
> > + bool "Present the stage-2 pagetables to debugfs"
> > + depends on PTDUMP_DEBUGFS && KVM
> > + default n
> > + help
> > + Say Y here if you want to show the stage-2 kernel pagetables
> > + layout in a debugfs file. This information is only useful for kernel developers
> > + who are working in architecture specific areas of the kernel.
> > + It is probably not a good idea to enable this feature in a production
> > + kernel.
> > +
> > + If in doubt, say N.
> > +
> > endif # VIRTUALIZATION
> > diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> > index c0c050e53157..190eac17538c 100644
> > --- a/arch/arm64/kvm/Makefile
> > +++ b/arch/arm64/kvm/Makefile
> > @@ -23,6 +23,7 @@ kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
> > vgic/vgic-its.o vgic/vgic-debug.o
> >
> > kvm-$(CONFIG_HW_PERF_EVENTS) += pmu-emul.o pmu.o
> > +kvm-$(CONFIG_PTDUMP_STAGE2_DEBUGFS) += ptdump.o
> >
> > always-y := hyp_constants.h hyp-constants.s
> >
> > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> > index 8725291cb00a..aef52836cd90 100644
> > --- a/arch/arm64/kvm/debug.c
> > +++ b/arch/arm64/kvm/debug.c
> > @@ -14,6 +14,8 @@
> > #include <asm/kvm_arm.h>
> > #include <asm/kvm_emulate.h>
> >
> > +#include <kvm_ptdump.h>
> > +
> > #include "trace.h"
> >
> > /* These are the bits of MDSCR_EL1 we may manipulate */
> > @@ -342,3 +344,8 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
> > vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_SPE);
> > vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
> > }
> > +
> > +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> > +{
> > + return kvm_ptdump_guest_register(kvm);
> > +}
> > diff --git a/arch/arm64/kvm/kvm_ptdump.h b/arch/arm64/kvm/kvm_ptdump.h
> > new file mode 100644
> > index 000000000000..a7c00a28481b
> > --- /dev/null
> > +++ b/arch/arm64/kvm/kvm_ptdump.h
> > @@ -0,0 +1,20 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) Google, 2023
> > + * Author: Sebastian Ene <sebastianene@google.com>
> > + */
> > +
> > +#ifndef __KVM_PTDUMP_H
> > +#define __KVM_PTDUMP_H
> > +
> > +#include <linux/kvm_host.h>
> > +#include <asm/ptdump.h>
> > +
> > +
> > +#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
> > +int kvm_ptdump_guest_register(struct kvm *kvm);
> > +#else
> > +static inline int kvm_ptdump_guest_register(struct kvm *kvm) { return 0; }
> > +#endif /* CONFIG_PTDUMP_STAGE2_DEBUGFS */
> > +
> > +#endif /* __KVM_PTDUMP_H */
> > diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> > new file mode 100644
> > index 000000000000..a4e984da8aa7
> > --- /dev/null
> > +++ b/arch/arm64/kvm/ptdump.c
> > @@ -0,0 +1,79 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +//
> > +// Debug helper used to dump the stage-2 pagetables of the system and their
> > +// associated permissions.
> > +//
> > +// Copyright (C) Google, 2023
> > +// Author: Sebastian Ene <sebastianene@google.com>
>
> Same comment as last time about ... the comment :)
>
> Should be of the form
>
> /*
> *
> */
>
I forgot to update this, sorry. Let me fix it.
> > +#include <linux/debugfs.h>
> > +#include <linux/kvm_host.h>
> > +#include <linux/seq_file.h>
> > +
> > +#include <asm/kvm_pkvm.h>
>
> is this needed?
>
We only need <asm/kvm_pgtable.h> so I will update this.
> > +#include <kvm_ptdump.h>
> > +
> > +
> > +static int kvm_ptdump_guest_open(struct inode *inode, struct file *file);
> > +static int kvm_ptdump_guest_show(struct seq_file *m, void *);
>
> can you structure the file in a way to avoid forward declarations?
>
Sounds good, let me drop those.
> > +static const struct file_operations kvm_ptdump_guest_fops = {
> > + .open = kvm_ptdump_guest_open,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release = single_release,
> > +};
> > +
> > +static int kvm_ptdump_guest_open(struct inode *inode, struct file *file)
> > +{
> > + return single_open(file, kvm_ptdump_guest_show, inode->i_private);
> > +}
> > +
>
> Shouldn't we take a reference on the KVM struct at open to avoid UAF?
>
> struct kvm *kvm = inode->i_private;
>
> if (!kvm_get_kvm_safe(kvm))
> return -ENOENT;
>
> Then you can do a put on it at close().
>
Thanks, I though that the kvm_destroy_vm_debugfs will keep spinning if
there are opened paths to the debugfs entry, but I guess nothing prevents
that from happening and the kvm struct can be removed behind our back.
> > +static int kvm_ptdump_visitor(const struct kvm_pgtable_visit_ctx *ctx,
> > + enum kvm_pgtable_walk_flags visit)
> > +{
> > + struct pg_state *st = ctx->arg;
> > + struct ptdump_state *pt_st = &st->ptdump;
> > +
> > + note_page(pt_st, ctx->addr, ctx->level, ctx->old);
> > + return 0;
> > +}
> > +
> > +static int kvm_ptdump_show_common(struct seq_file *m,
> > + struct kvm_pgtable *pgtable,
> > + struct pg_state *parser_state)
> > +{
> > + struct kvm_pgtable_walker walker = (struct kvm_pgtable_walker) {
> > + .cb = kvm_ptdump_visitor,
> > + .arg = parser_state,
> > + .flags = KVM_PGTABLE_WALK_LEAF,
> > + };
> > +
> > + return kvm_pgtable_walk(pgtable, 0, BIT(pgtable->ia_bits), &walker);
> > +}
> > +
> > +static int kvm_ptdump_guest_show(struct seq_file *m, void *)
> > +{
> > + struct kvm *guest_kvm = m->private;
> > + struct kvm_s2_mmu *mmu = &guest_kvm->arch.mmu;
> > + struct pg_state parser_state = {0};
> > + int ret;
> > +
> > + write_lock(&guest_kvm->mmu_lock);
> > + ret = kvm_ptdump_show_common(m, mmu->pgt, &parser_state);
> > + write_unlock(&guest_kvm->mmu_lock);
> > +
> > + return ret;
> > +}
> > +
> > +int kvm_ptdump_guest_register(struct kvm *kvm)
> > +{
> > + struct dentry *parent;
> > +
> > + parent = debugfs_create_file("stage2_page_tables", 0400,
> > + kvm->debugfs_dentry, kvm,
> > + &kvm_ptdump_guest_fops);
> > + if (IS_ERR(parent))
> > + return PTR_ERR(parent);
>
> This makes the otherwise benign debugfs failure into something fatal for
> VM creation, no?
>
> From the documentation on debugfs_create_file():
>
> * NOTE: it's expected that most callers should _ignore_ the errors returned
> * by this function. Other debugfs functions handle the fact that the "dentry"
> * passed to them could be an error and they don't crash in that case.
> * Drivers should generally work fine even if debugfs fails to init anyway.
>
> The fact that kvm_arch_create_vm_debugfs() has a return value is a bit
> of an anti-pattern to begin with.
>
Ack, I will ignore the retun code then.
> --
> Thanks,
> Oliver
Thanks,
Sebastian
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Ene <sebastianene@google.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: catalin.marinas@arm.com, gshan@redhat.com, james.morse@arm.com,
mark.rutland@arm.com, maz@kernel.org, rananta@google.com,
ricarkol@google.com, ryan.roberts@arm.com, shahuang@redhat.com,
suzuki.poulose@arm.com, will@kernel.org, yuzenghui@huawei.com,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel-team@android.com,
vdonnefort@google.com
Subject: Re: [PATCH v5 3/4] KVM: arm64: Register ptdump with debugfs on guest creation
Date: Tue, 13 Feb 2024 16:42:27 +0000 [thread overview]
Message-ID: <Zcub87FwaVPkCXQE@google.com> (raw)
In-Reply-To: <Zcq-NGa-Gd9rVVgF@linux.dev>
On Tue, Feb 13, 2024 at 12:56:20AM +0000, Oliver Upton wrote:
> On Wed, Feb 07, 2024 at 02:48:32PM +0000, Sebastian Ene wrote:
Hello Oliver,
> > While arch/*/mem/ptdump handles the kernel pagetable dumping code,
> > introduce KVM/ptdump which shows the guest stage-2 pagetables. The
> > separation is necessary because most of the definitions from the
> > stage-2 pagetable reside in the KVM path and we will be invoking
> > functionality **specific** to KVM.
> >
> > When a guest is created, register a new file entry under the guest
> > debugfs dir which allows userspace to show the contents of the guest
> > stage-2 pagetables when accessed.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/Kconfig | 13 ++++++
> > arch/arm64/kvm/Makefile | 1 +
> > arch/arm64/kvm/debug.c | 7 ++++
> > arch/arm64/kvm/kvm_ptdump.h | 20 ++++++++++
> > arch/arm64/kvm/ptdump.c | 79 +++++++++++++++++++++++++++++++++++++
> > 5 files changed, 120 insertions(+)
> > create mode 100644 arch/arm64/kvm/kvm_ptdump.h
> > create mode 100644 arch/arm64/kvm/ptdump.c
> >
> > diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> > index 6c3c8ca73e7f..28097dd72174 100644
> > --- a/arch/arm64/kvm/Kconfig
> > +++ b/arch/arm64/kvm/Kconfig
> > @@ -68,4 +68,17 @@ config PROTECTED_NVHE_STACKTRACE
> >
> > If unsure, or not using protected nVHE (pKVM), say N.
> >
> > +config PTDUMP_STAGE2_DEBUGFS
> > + bool "Present the stage-2 pagetables to debugfs"
> > + depends on PTDUMP_DEBUGFS && KVM
> > + default n
> > + help
> > + Say Y here if you want to show the stage-2 kernel pagetables
> > + layout in a debugfs file. This information is only useful for kernel developers
> > + who are working in architecture specific areas of the kernel.
> > + It is probably not a good idea to enable this feature in a production
> > + kernel.
> > +
> > + If in doubt, say N.
> > +
> > endif # VIRTUALIZATION
> > diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> > index c0c050e53157..190eac17538c 100644
> > --- a/arch/arm64/kvm/Makefile
> > +++ b/arch/arm64/kvm/Makefile
> > @@ -23,6 +23,7 @@ kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
> > vgic/vgic-its.o vgic/vgic-debug.o
> >
> > kvm-$(CONFIG_HW_PERF_EVENTS) += pmu-emul.o pmu.o
> > +kvm-$(CONFIG_PTDUMP_STAGE2_DEBUGFS) += ptdump.o
> >
> > always-y := hyp_constants.h hyp-constants.s
> >
> > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> > index 8725291cb00a..aef52836cd90 100644
> > --- a/arch/arm64/kvm/debug.c
> > +++ b/arch/arm64/kvm/debug.c
> > @@ -14,6 +14,8 @@
> > #include <asm/kvm_arm.h>
> > #include <asm/kvm_emulate.h>
> >
> > +#include <kvm_ptdump.h>
> > +
> > #include "trace.h"
> >
> > /* These are the bits of MDSCR_EL1 we may manipulate */
> > @@ -342,3 +344,8 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
> > vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_SPE);
> > vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
> > }
> > +
> > +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> > +{
> > + return kvm_ptdump_guest_register(kvm);
> > +}
> > diff --git a/arch/arm64/kvm/kvm_ptdump.h b/arch/arm64/kvm/kvm_ptdump.h
> > new file mode 100644
> > index 000000000000..a7c00a28481b
> > --- /dev/null
> > +++ b/arch/arm64/kvm/kvm_ptdump.h
> > @@ -0,0 +1,20 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) Google, 2023
> > + * Author: Sebastian Ene <sebastianene@google.com>
> > + */
> > +
> > +#ifndef __KVM_PTDUMP_H
> > +#define __KVM_PTDUMP_H
> > +
> > +#include <linux/kvm_host.h>
> > +#include <asm/ptdump.h>
> > +
> > +
> > +#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
> > +int kvm_ptdump_guest_register(struct kvm *kvm);
> > +#else
> > +static inline int kvm_ptdump_guest_register(struct kvm *kvm) { return 0; }
> > +#endif /* CONFIG_PTDUMP_STAGE2_DEBUGFS */
> > +
> > +#endif /* __KVM_PTDUMP_H */
> > diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> > new file mode 100644
> > index 000000000000..a4e984da8aa7
> > --- /dev/null
> > +++ b/arch/arm64/kvm/ptdump.c
> > @@ -0,0 +1,79 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +//
> > +// Debug helper used to dump the stage-2 pagetables of the system and their
> > +// associated permissions.
> > +//
> > +// Copyright (C) Google, 2023
> > +// Author: Sebastian Ene <sebastianene@google.com>
>
> Same comment as last time about ... the comment :)
>
> Should be of the form
>
> /*
> *
> */
>
I forgot to update this, sorry. Let me fix it.
> > +#include <linux/debugfs.h>
> > +#include <linux/kvm_host.h>
> > +#include <linux/seq_file.h>
> > +
> > +#include <asm/kvm_pkvm.h>
>
> is this needed?
>
We only need <asm/kvm_pgtable.h> so I will update this.
> > +#include <kvm_ptdump.h>
> > +
> > +
> > +static int kvm_ptdump_guest_open(struct inode *inode, struct file *file);
> > +static int kvm_ptdump_guest_show(struct seq_file *m, void *);
>
> can you structure the file in a way to avoid forward declarations?
>
Sounds good, let me drop those.
> > +static const struct file_operations kvm_ptdump_guest_fops = {
> > + .open = kvm_ptdump_guest_open,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release = single_release,
> > +};
> > +
> > +static int kvm_ptdump_guest_open(struct inode *inode, struct file *file)
> > +{
> > + return single_open(file, kvm_ptdump_guest_show, inode->i_private);
> > +}
> > +
>
> Shouldn't we take a reference on the KVM struct at open to avoid UAF?
>
> struct kvm *kvm = inode->i_private;
>
> if (!kvm_get_kvm_safe(kvm))
> return -ENOENT;
>
> Then you can do a put on it at close().
>
Thanks, I though that the kvm_destroy_vm_debugfs will keep spinning if
there are opened paths to the debugfs entry, but I guess nothing prevents
that from happening and the kvm struct can be removed behind our back.
> > +static int kvm_ptdump_visitor(const struct kvm_pgtable_visit_ctx *ctx,
> > + enum kvm_pgtable_walk_flags visit)
> > +{
> > + struct pg_state *st = ctx->arg;
> > + struct ptdump_state *pt_st = &st->ptdump;
> > +
> > + note_page(pt_st, ctx->addr, ctx->level, ctx->old);
> > + return 0;
> > +}
> > +
> > +static int kvm_ptdump_show_common(struct seq_file *m,
> > + struct kvm_pgtable *pgtable,
> > + struct pg_state *parser_state)
> > +{
> > + struct kvm_pgtable_walker walker = (struct kvm_pgtable_walker) {
> > + .cb = kvm_ptdump_visitor,
> > + .arg = parser_state,
> > + .flags = KVM_PGTABLE_WALK_LEAF,
> > + };
> > +
> > + return kvm_pgtable_walk(pgtable, 0, BIT(pgtable->ia_bits), &walker);
> > +}
> > +
> > +static int kvm_ptdump_guest_show(struct seq_file *m, void *)
> > +{
> > + struct kvm *guest_kvm = m->private;
> > + struct kvm_s2_mmu *mmu = &guest_kvm->arch.mmu;
> > + struct pg_state parser_state = {0};
> > + int ret;
> > +
> > + write_lock(&guest_kvm->mmu_lock);
> > + ret = kvm_ptdump_show_common(m, mmu->pgt, &parser_state);
> > + write_unlock(&guest_kvm->mmu_lock);
> > +
> > + return ret;
> > +}
> > +
> > +int kvm_ptdump_guest_register(struct kvm *kvm)
> > +{
> > + struct dentry *parent;
> > +
> > + parent = debugfs_create_file("stage2_page_tables", 0400,
> > + kvm->debugfs_dentry, kvm,
> > + &kvm_ptdump_guest_fops);
> > + if (IS_ERR(parent))
> > + return PTR_ERR(parent);
>
> This makes the otherwise benign debugfs failure into something fatal for
> VM creation, no?
>
> From the documentation on debugfs_create_file():
>
> * NOTE: it's expected that most callers should _ignore_ the errors returned
> * by this function. Other debugfs functions handle the fact that the "dentry"
> * passed to them could be an error and they don't crash in that case.
> * Drivers should generally work fine even if debugfs fails to init anyway.
>
> The fact that kvm_arch_create_vm_debugfs() has a return value is a bit
> of an anti-pattern to begin with.
>
Ack, I will ignore the retun code then.
> --
> Thanks,
> Oliver
Thanks,
Sebastian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-13 16:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-07 14:48 [PATCH v5 0/4] arm64: ptdump: View the second stage page-tables Sebastian Ene
2024-02-07 14:48 ` Sebastian Ene
2024-02-07 14:48 ` [PATCH v5 1/4] arm64: ptdump: Expose the attribute parsing functionality Sebastian Ene
2024-02-07 14:48 ` Sebastian Ene
2024-02-07 14:48 ` [PATCH v5 2/4] arm64: ptdump: Use the mask from the state structure Sebastian Ene
2024-02-07 14:48 ` Sebastian Ene
2024-02-07 14:48 ` [PATCH v5 3/4] KVM: arm64: Register ptdump with debugfs on guest creation Sebastian Ene
2024-02-07 14:48 ` Sebastian Ene
2024-02-13 0:56 ` Oliver Upton
2024-02-13 0:56 ` Oliver Upton
2024-02-13 16:42 ` Sebastian Ene [this message]
2024-02-13 16:42 ` Sebastian Ene
2024-02-13 16:51 ` Oliver Upton
2024-02-13 16:51 ` Oliver Upton
2024-02-07 14:48 ` [PATCH v5 4/4] KVM: arm64: Initialize the ptdump parser with stage-2 attributes Sebastian Ene
2024-02-07 14:48 ` Sebastian Ene
2024-02-13 0:42 ` Oliver Upton
2024-02-13 0:42 ` Oliver Upton
2024-02-13 16:59 ` Sebastian Ene
2024-02-13 16:59 ` Sebastian Ene
2024-02-13 17:10 ` Oliver Upton
2024-02-13 17:10 ` Oliver Upton
2024-02-14 16:29 ` Sebastian Ene
2024-02-14 16:29 ` Sebastian Ene
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=Zcub87FwaVPkCXQE@google.com \
--to=sebastianene@google.com \
--cc=catalin.marinas@arm.com \
--cc=gshan@redhat.com \
--cc=james.morse@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=rananta@google.com \
--cc=ricarkol@google.com \
--cc=ryan.roberts@arm.com \
--cc=shahuang@redhat.com \
--cc=suzuki.poulose@arm.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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.