From: Deepak Gupta <debug@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: rick.p.edgecombe@intel.com, broonie@kernel.org,
Szabolcs.Nagy@arm.com, kito.cheng@sifive.com,
keescook@chromium.org, ajones@ventanamicro.com,
paul.walmsley@sifive.com, palmer@dabbelt.com,
conor.dooley@microchip.com, cleger@rivosinc.com,
atishp@atishpatra.org, alex@ghiti.fr, bjorn@rivosinc.com,
alexghiti@rivosinc.com, corbet@lwn.net, aou@eecs.berkeley.edu,
oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de,
ebiederm@xmission.com, shuah@kernel.org, brauner@kernel.org,
guoren@kernel.org, samitolvanen@google.com, evan@rivosinc.com,
xiao.w.wang@intel.com, apatel@ventanamicro.com,
mchitale@ventanamicro.com, waylingii@gmail.com,
greentime.hu@sifive.com, heiko@sntech.de, jszhang@kernel.org,
shikemeng@huaweicloud.com, david@redhat.com,
charlie@rivosinc.com, panqinglin2020@iscas.ac.cn,
willy@infradead.org, vincent.chen@sifive.com,
andy.chiu@sifive.com, gerg@kernel.org,
jeeheng.sia@starfivetech.com, mason.huo@starfivetech.com,
ancientmodern4@gmail.com, mathis.salmen@matsal.de,
cuiyunhui@bytedance.com, bhe@redhat.com, ruscur@russell.cc,
bgray@linux.ibm.com, alx@kernel.org, baruch@tkos.co.il,
zhangqing@loongson.cn, catalin.marinas@arm.com,
revest@chromium.org, josh@joshtriplett.org, joey.gouly@arm.com,
shr@devkernel.io, omosnace@redhat.com, ojeda@kernel.org,
jhubbard@nvidia.com, linux-doc@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [RFC PATCH v1 05/28] riscv: zicfiss/zicfilp enumeration
Date: Thu, 25 Jan 2024 10:26:19 -0800 [thread overview]
Message-ID: <ZbKny7ZAG5FWHwwF@debug.ba.rivosinc.com> (raw)
In-Reply-To: <20240125-unscathed-coeditor-31f04e811489@spud>
On Thu, Jan 25, 2024 at 05:59:24PM +0000, Conor Dooley wrote:
>Yo,
>
>Series is RFC, so not gonna review it in depth, just wanted to comment
>on this particular patch.
>
>On Wed, Jan 24, 2024 at 10:21:30PM -0800, debug@rivosinc.com wrote:
>> From: Deepak Gupta <debug@rivosinc.com>
>>
>> This patch adds support for detecting zicfiss and zicfilp. zicfiss and zicfilp
>> stands for unprivleged integer spec extension for shadow stack and branch
>> tracking on indirect branches, respectively.
>>
>> This patch looks for zicfiss and zicfilp in device tree and accordinlgy lights
>> up bit in cpu feature bitmap. Furthermore this patch adds detection utility
>> functions to return whether shadow stack or landing pads are supported by
>> cpu.
>>
>> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
>> ---
>> arch/riscv/include/asm/cpufeature.h | 18 ++++++++++++++++++
>> arch/riscv/include/asm/hwcap.h | 2 ++
>> arch/riscv/include/asm/processor.h | 1 +
>> arch/riscv/kernel/cpufeature.c | 2 ++
>> 4 files changed, 23 insertions(+)
>>
>> diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
>> index a418c3112cd6..216190731c55 100644
>> --- a/arch/riscv/include/asm/cpufeature.h
>> +++ b/arch/riscv/include/asm/cpufeature.h
>> @@ -133,4 +133,22 @@ static __always_inline bool riscv_cpu_has_extension_unlikely(int cpu, const unsi
>> return __riscv_isa_extension_available(hart_isa[cpu].isa, ext);
>> }
>>
>> +static inline bool cpu_supports_shadow_stack(void)
>> +{
>> +#ifdef CONFIG_RISCV_USER_CFI
>
>In passing, I don't see any reason for not using IS_ENABLED() here.
No reason. I should probably do that. More readable.
Thanks.
>
>> + return riscv_isa_extension_available(NULL, ZICFISS);
>> +#else
>> + return false;
>> +#endif
>> +}
>> +
>> +static inline bool cpu_supports_indirect_br_lp_instr(void)
>> +{
>> +#ifdef CONFIG_RISCV_USER_CFI
>> + return riscv_isa_extension_available(NULL, ZICFILP);
>> +#else
>> + return false;
>> +#endif
>> +}
>> +
>> #endif
>> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
>> index 06d30526ef3b..918165cfb4fa 100644
>> --- a/arch/riscv/include/asm/hwcap.h
>> +++ b/arch/riscv/include/asm/hwcap.h
>> @@ -57,6 +57,8 @@
>> #define RISCV_ISA_EXT_ZIHPM 42
>> #define RISCV_ISA_EXT_SMSTATEEN 43
>> #define RISCV_ISA_EXT_ZICOND 44
>> +#define RISCV_ISA_EXT_ZICFISS 45
>> +#define RISCV_ISA_EXT_ZICFILP 46
>>
>> #define RISCV_ISA_EXT_MAX 64
>>
>> diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
>> index f19f861cda54..ee2f51787ff8 100644
>> --- a/arch/riscv/include/asm/processor.h
>> +++ b/arch/riscv/include/asm/processor.h
>> @@ -13,6 +13,7 @@
>> #include <vdso/processor.h>
>>
>> #include <asm/ptrace.h>
>> +#include <asm/hwcap.h>
>>
>> #ifdef CONFIG_64BIT
>> #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
>> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
>> index 98623393fd1f..16624bc9a46b 100644
>> --- a/arch/riscv/kernel/cpufeature.c
>> +++ b/arch/riscv/kernel/cpufeature.c
>> @@ -185,6 +185,8 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
>> __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
>> __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT),
>> __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
>> + __RISCV_ISA_EXT_DATA(zicfiss, RISCV_ISA_EXT_ZICFISS),
>> + __RISCV_ISA_EXT_DATA(zicfilp, RISCV_ISA_EXT_ZICFILP),
>
>Anything you add to this array, you need to document in a dt-binding.
You mean Documentation/devicetree/bindings/riscv/extensions.yaml
(or possibly any other yaml if needed?)
>Also, you added these in the wrong place. There's a massive comment
>before the array describing the order entries must be in, please take a
>look.
I see the comment.
In my defense, looks like I missed it when I was rebasing.
Will fix it.
>
>Thanks,
>Conor.
>
>
>> };
>>
>> const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
>> --
>> 2.43.0
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Deepak Gupta <debug@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: rick.p.edgecombe@intel.com, broonie@kernel.org,
Szabolcs.Nagy@arm.com, kito.cheng@sifive.com,
keescook@chromium.org, ajones@ventanamicro.com,
paul.walmsley@sifive.com, palmer@dabbelt.com,
conor.dooley@microchip.com, cleger@rivosinc.com,
atishp@atishpatra.org, alex@ghiti.fr, bjorn@rivosinc.com,
alexghiti@rivosinc.com, corbet@lwn.net, aou@eecs.berkeley.edu,
oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de,
ebiederm@xmission.com, shuah@kernel.org, brauner@kernel.org,
guoren@kernel.org, samitolvanen@google.com, evan@rivosinc.com,
xiao.w.wang@intel.com, apatel@ventanamicro.com,
mchitale@ventanamicro.com, waylingii@gmail.com,
greentime.hu@sifive.com, heiko@sntech.de, jszhang@kernel.org,
shikemeng@huaweicloud.com, david@redhat.com,
charlie@rivosinc.com, panqinglin2020@iscas.ac.cn,
willy@infradead.org, vincent.chen@sifive.com,
andy.chiu@sifive.com, gerg@kernel.org,
jeeheng.sia@starfivetech.com, mason.huo@starfivetech.com,
ancientmodern4@gmail.com, mathis.salmen@matsal.de,
cuiyunhui@bytedance.com, bhe@redhat.com, ruscur@russell.cc,
bgray@linux.ibm.com, alx@kernel.org, baruch@tkos.co.il,
zhangqing@loongson.cn, catalin.marinas@arm.com,
revest@chromium.org, josh@joshtriplett.org, joey.gouly@arm.com,
shr@devkernel.io, omosnace@redhat.com, ojeda@kernel.org,
jhubbard@nvidia.com, linux-doc@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [RFC PATCH v1 05/28] riscv: zicfiss/zicfilp enumeration
Date: Thu, 25 Jan 2024 10:26:19 -0800 [thread overview]
Message-ID: <ZbKny7ZAG5FWHwwF@debug.ba.rivosinc.com> (raw)
In-Reply-To: <20240125-unscathed-coeditor-31f04e811489@spud>
On Thu, Jan 25, 2024 at 05:59:24PM +0000, Conor Dooley wrote:
>Yo,
>
>Series is RFC, so not gonna review it in depth, just wanted to comment
>on this particular patch.
>
>On Wed, Jan 24, 2024 at 10:21:30PM -0800, debug@rivosinc.com wrote:
>> From: Deepak Gupta <debug@rivosinc.com>
>>
>> This patch adds support for detecting zicfiss and zicfilp. zicfiss and zicfilp
>> stands for unprivleged integer spec extension for shadow stack and branch
>> tracking on indirect branches, respectively.
>>
>> This patch looks for zicfiss and zicfilp in device tree and accordinlgy lights
>> up bit in cpu feature bitmap. Furthermore this patch adds detection utility
>> functions to return whether shadow stack or landing pads are supported by
>> cpu.
>>
>> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
>> ---
>> arch/riscv/include/asm/cpufeature.h | 18 ++++++++++++++++++
>> arch/riscv/include/asm/hwcap.h | 2 ++
>> arch/riscv/include/asm/processor.h | 1 +
>> arch/riscv/kernel/cpufeature.c | 2 ++
>> 4 files changed, 23 insertions(+)
>>
>> diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
>> index a418c3112cd6..216190731c55 100644
>> --- a/arch/riscv/include/asm/cpufeature.h
>> +++ b/arch/riscv/include/asm/cpufeature.h
>> @@ -133,4 +133,22 @@ static __always_inline bool riscv_cpu_has_extension_unlikely(int cpu, const unsi
>> return __riscv_isa_extension_available(hart_isa[cpu].isa, ext);
>> }
>>
>> +static inline bool cpu_supports_shadow_stack(void)
>> +{
>> +#ifdef CONFIG_RISCV_USER_CFI
>
>In passing, I don't see any reason for not using IS_ENABLED() here.
No reason. I should probably do that. More readable.
Thanks.
>
>> + return riscv_isa_extension_available(NULL, ZICFISS);
>> +#else
>> + return false;
>> +#endif
>> +}
>> +
>> +static inline bool cpu_supports_indirect_br_lp_instr(void)
>> +{
>> +#ifdef CONFIG_RISCV_USER_CFI
>> + return riscv_isa_extension_available(NULL, ZICFILP);
>> +#else
>> + return false;
>> +#endif
>> +}
>> +
>> #endif
>> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
>> index 06d30526ef3b..918165cfb4fa 100644
>> --- a/arch/riscv/include/asm/hwcap.h
>> +++ b/arch/riscv/include/asm/hwcap.h
>> @@ -57,6 +57,8 @@
>> #define RISCV_ISA_EXT_ZIHPM 42
>> #define RISCV_ISA_EXT_SMSTATEEN 43
>> #define RISCV_ISA_EXT_ZICOND 44
>> +#define RISCV_ISA_EXT_ZICFISS 45
>> +#define RISCV_ISA_EXT_ZICFILP 46
>>
>> #define RISCV_ISA_EXT_MAX 64
>>
>> diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
>> index f19f861cda54..ee2f51787ff8 100644
>> --- a/arch/riscv/include/asm/processor.h
>> +++ b/arch/riscv/include/asm/processor.h
>> @@ -13,6 +13,7 @@
>> #include <vdso/processor.h>
>>
>> #include <asm/ptrace.h>
>> +#include <asm/hwcap.h>
>>
>> #ifdef CONFIG_64BIT
>> #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
>> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
>> index 98623393fd1f..16624bc9a46b 100644
>> --- a/arch/riscv/kernel/cpufeature.c
>> +++ b/arch/riscv/kernel/cpufeature.c
>> @@ -185,6 +185,8 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
>> __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
>> __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT),
>> __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
>> + __RISCV_ISA_EXT_DATA(zicfiss, RISCV_ISA_EXT_ZICFISS),
>> + __RISCV_ISA_EXT_DATA(zicfilp, RISCV_ISA_EXT_ZICFILP),
>
>Anything you add to this array, you need to document in a dt-binding.
You mean Documentation/devicetree/bindings/riscv/extensions.yaml
(or possibly any other yaml if needed?)
>Also, you added these in the wrong place. There's a massive comment
>before the array describing the order entries must be in, please take a
>look.
I see the comment.
In my defense, looks like I missed it when I was rebasing.
Will fix it.
>
>Thanks,
>Conor.
>
>
>> };
>>
>> const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
>> --
>> 2.43.0
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-01-25 18:26 UTC|newest]
Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 6:21 [RFC PATCH v1 00/28] riscv control-flow integrity for usermode debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 01/28] riscv: abstract envcfg CSR debug
2024-01-25 6:21 ` debug
2024-02-12 10:23 ` Andrew Jones
2024-02-12 10:23 ` Andrew Jones
2024-01-25 6:21 ` [RFC PATCH v1 02/28] riscv: envcfg save and restore on trap entry/exit debug
2024-01-25 6:21 ` debug
2024-01-25 7:19 ` Stefan O'Rear
2024-01-25 7:19 ` Stefan O'Rear
2024-01-25 17:09 ` Deepak Gupta
2024-01-25 17:09 ` Deepak Gupta
2024-01-25 17:54 ` Deepak Gupta
2024-01-25 17:54 ` Deepak Gupta
2024-01-25 6:21 ` [RFC PATCH v1 03/28] riscv: define default value for envcfg debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 04/28] riscv/Kconfig: enable HAVE_EXIT_THREAD for riscv debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 05/28] riscv: zicfiss/zicfilp enumeration debug
2024-01-25 6:21 ` debug
2024-01-25 17:59 ` Conor Dooley
2024-01-25 17:59 ` Conor Dooley
2024-01-25 18:26 ` Deepak Gupta [this message]
2024-01-25 18:26 ` Deepak Gupta
2024-01-25 18:46 ` Conor Dooley
2024-01-25 18:46 ` Conor Dooley
2024-01-25 6:21 ` [RFC PATCH v1 06/28] riscv: zicfiss/zicfilp extension csr and bit definitions debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 07/28] riscv: kernel handling on trap entry/exit for user cfi debug
2024-01-25 6:21 ` debug
2024-01-25 7:29 ` Stefan O'Rear
2024-01-25 7:29 ` Stefan O'Rear
2024-01-25 17:30 ` Deepak Gupta
2024-01-25 17:30 ` Deepak Gupta
2024-01-25 19:47 ` Stefan O'Rear
2024-01-25 19:47 ` Stefan O'Rear
2024-01-26 0:25 ` Deepak Gupta
2024-01-26 0:25 ` Deepak Gupta
2024-01-25 6:21 ` [RFC PATCH v1 08/28] mm: Define VM_SHADOW_STACK for RISC-V debug
2024-01-25 6:21 ` debug
2024-01-25 8:17 ` David Hildenbrand
2024-01-25 8:17 ` David Hildenbrand
2024-01-25 17:05 ` Deepak Gupta
2024-01-25 17:05 ` Deepak Gupta
2024-01-25 6:21 ` [RFC PATCH v1 09/28] mm: abstract shadow stack vma behind `arch_is_shadow_stack` debug
2024-01-25 6:21 ` debug
2024-01-25 8:18 ` David Hildenbrand
2024-01-25 8:18 ` David Hildenbrand
2024-01-25 17:07 ` Deepak Gupta
2024-01-25 17:07 ` Deepak Gupta
2024-02-13 10:34 ` David Hildenbrand
2024-02-13 10:34 ` David Hildenbrand
2024-02-22 1:32 ` Deepak Gupta
2024-02-22 1:32 ` Deepak Gupta
2024-01-25 6:21 ` [RFC PATCH v1 10/28] riscv/mm : Introducing new protection flag "PROT_SHADOWSTACK" debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 11/28] riscv: Implementing "PROT_SHADOWSTACK" on riscv debug
2024-01-25 6:21 ` debug
2024-02-09 20:44 ` Edgecombe, Rick P
2024-02-09 20:44 ` Edgecombe, Rick P
2024-02-22 0:39 ` Deepak Gupta
2024-02-22 0:39 ` Deepak Gupta
2024-01-25 6:21 ` [RFC PATCH v1 12/28] riscv mm: manufacture shadow stack pte debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 13/28] riscv mmu: teach pte_mkwrite to manufacture shadow stack PTEs debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 14/28] riscv mmu: write protect and shadow stack debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 15/28] riscv/mm: Implement map_shadow_stack() syscall debug
2024-01-25 6:21 ` debug
2024-01-25 21:24 ` Charlie Jenkins
2024-01-25 21:24 ` Charlie Jenkins
2024-01-26 0:44 ` Deepak Gupta
2024-01-26 0:44 ` Deepak Gupta
2024-02-06 16:01 ` Mark Brown
2024-02-06 16:01 ` Mark Brown
2024-02-22 0:47 ` Deepak Gupta
2024-02-22 0:47 ` Deepak Gupta
2024-02-22 13:33 ` Mark Brown
2024-02-22 13:33 ` Mark Brown
2024-02-09 20:44 ` Edgecombe, Rick P
2024-02-09 20:44 ` Edgecombe, Rick P
2024-02-22 0:50 ` Deepak Gupta
2024-02-22 0:50 ` Deepak Gupta
2024-01-25 6:21 ` [RFC PATCH v1 16/28] riscv/shstk: If needed allocate a new shadow stack on clone debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 17/28] prctl: arch-agnostic prctl for shadow stack debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 18/28] prctl: arch-agnostic prtcl for indirect branch tracking debug
2024-01-25 6:21 ` debug
2024-02-06 16:13 ` Mark Brown
2024-02-06 16:13 ` Mark Brown
2024-02-22 0:42 ` Deepak Gupta
2024-02-22 0:42 ` Deepak Gupta
2024-01-25 6:21 ` [RFC PATCH v1 19/28] riscv: Implements arch agnostic shadow stack prctls debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 20/28] riscv: Implements arch argnostic indirect branch tracking prctls debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 21/28] riscv/traps: Introduce software check exception debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 22/28] riscv sigcontext: adding cfi state field in sigcontext debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 23/28] riscv signal: Save and restore of shadow stack for signal debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 24/28] riscv: select config for shadow stack and landing pad instr support debug
2024-01-25 6:21 ` debug
2024-01-25 18:04 ` Conor Dooley
2024-01-25 18:04 ` Conor Dooley
2024-01-25 18:12 ` Deepak Gupta
2024-01-25 18:12 ` Deepak Gupta
2024-01-25 18:44 ` Conor Dooley
2024-01-25 18:44 ` Conor Dooley
2024-01-25 19:26 ` Deepak Gupta
2024-01-25 19:26 ` Deepak Gupta
2024-01-25 6:21 ` [RFC PATCH v1 25/28] riscv/ptrace: riscv cfi status and state via ptrace and in core files debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 26/28] riscv: Documentation for landing pad / indirect branch tracking debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 27/28] riscv: Documentation for shadow stack on riscv debug
2024-01-25 6:21 ` debug
2024-01-25 6:21 ` [RFC PATCH v1 28/28] kselftest/riscv: kselftest for user mode cfi debug
2024-01-25 6:21 ` debug
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=ZbKny7ZAG5FWHwwF@debug.ba.rivosinc.com \
--to=debug@rivosinc.com \
--cc=Szabolcs.Nagy@arm.com \
--cc=ajones@ventanamicro.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=alexghiti@rivosinc.com \
--cc=alx@kernel.org \
--cc=ancientmodern4@gmail.com \
--cc=andy.chiu@sifive.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=arnd@arndb.de \
--cc=atishp@atishpatra.org \
--cc=baruch@tkos.co.il \
--cc=bgray@linux.ibm.com \
--cc=bhe@redhat.com \
--cc=bjorn@rivosinc.com \
--cc=brauner@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=charlie@rivosinc.com \
--cc=cleger@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=corbet@lwn.net \
--cc=cuiyunhui@bytedance.com \
--cc=david@redhat.com \
--cc=ebiederm@xmission.com \
--cc=evan@rivosinc.com \
--cc=gerg@kernel.org \
--cc=greentime.hu@sifive.com \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--cc=jeeheng.sia@starfivetech.com \
--cc=jhubbard@nvidia.com \
--cc=joey.gouly@arm.com \
--cc=josh@joshtriplett.org \
--cc=jszhang@kernel.org \
--cc=keescook@chromium.org \
--cc=kito.cheng@sifive.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mason.huo@starfivetech.com \
--cc=mathis.salmen@matsal.de \
--cc=mchitale@ventanamicro.com \
--cc=ojeda@kernel.org \
--cc=oleg@redhat.com \
--cc=omosnace@redhat.com \
--cc=palmer@dabbelt.com \
--cc=panqinglin2020@iscas.ac.cn \
--cc=paul.walmsley@sifive.com \
--cc=revest@chromium.org \
--cc=rick.p.edgecombe@intel.com \
--cc=ruscur@russell.cc \
--cc=samitolvanen@google.com \
--cc=shikemeng@huaweicloud.com \
--cc=shr@devkernel.io \
--cc=shuah@kernel.org \
--cc=vincent.chen@sifive.com \
--cc=waylingii@gmail.com \
--cc=willy@infradead.org \
--cc=xiao.w.wang@intel.com \
--cc=zhangqing@loongson.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.