From: Deepak Gupta <debug@rivosinc.com>
To: Paul Walmsley <pjw@kernel.org>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Conor Dooley" <conor@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Christian Brauner" <brauner@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Oleg Nesterov" <oleg@redhat.com>,
"Eric Biederman" <ebiederm@xmission.com>,
"Kees Cook" <kees@kernel.org>, "Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <shuah@kernel.org>, "Jann Horn" <jannh@google.com>,
"Conor Dooley" <conor+dt@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Benno Lossin" <lossin@kernel.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-riscv@lists.infradead.org,
devicetree@vger.kernel.org, linux-arch@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
alistair.francis@wdc.com, richard.henderson@linaro.org,
jim.shu@sifive.com, "Andy Chiu" <andybnac@gmail.com>,
kito.cheng@sifive.com, charlie@rivosinc.com, atishp@rivosinc.com,
evan@rivosinc.com, cleger@rivosinc.com, alexghiti@rivosinc.com,
samitolvanen@google.com, broonie@kernel.org,
rick.p.edgecombe@intel.com, rust-for-linux@vger.kernel.org,
"Zong Li" <zong.li@sifive.com>,
"David Hildenbrand" <david@redhat.com>,
"Andreas Korb" <andreas.korb@aisec.fraunhofer.de>,
"Valentin Haudiquet" <valentin.haudiquet@canonical.com>,
"Charles Mirabile" <cmirabil@redhat.com>
Subject: Re: [PATCH v26 00/28] riscv control-flow integrity for usermode
Date: Fri, 12 Dec 2025 10:33:16 -0800 [thread overview]
Message-ID: <aTxf7IGlkGLgHgI2@debug.ba.rivosinc.com> (raw)
In-Reply-To: <e052745b-6bf0-c2a3-21b2-5ecd8b04ec70@kernel.org>
On Fri, Dec 12, 2025 at 01:30:29AM -0700, Paul Walmsley wrote:
>On Thu, 11 Dec 2025, Deepak Gupta via B4 Relay wrote:
>
>> v26: CONFIG_RISCV_USER_CFI depends on CONFIG_MMU (dependency of shadow stack
>> on MMU). Used b4 to pick tags, apparantly it messed up some tag picks. Fixing it
>
>Deepak: I'm now (at least) the third person to tell you to stop resending
>this entire series over and over again.
To be very honest I also feel very bad doing and DOSing the lists. Sorry to you
and everyone else.
But I have been sitting on this patch series for last 3-4 merge windows with
patches being exactly same/similar. So I have been a little more than desperate
to get it in.
I really haven't had any meaningful feedback on patch series except stalling
just before each merge window for reasons which really shouldn't stall its
merge. Sure that's the nature of open source development and it's maintainer's
call at the end of the day. And I am new to this. I'll improve.
>
>First, a modified version of the CFI v23 series was ALREADY SITTING IN
>LINUX-NEXT. So there's no reason you should be resending the entire
>series, UNLESS your intention for me is to drop the entire existing series
>and wait for another merge window.
>
>Second: when someone asks you questions about an individual patch, and you
>want to answer those questions, it's NOT GOOD for you to resend the entire
>28 series as the response! You are DDOSing a bunch of lists and E-mail
>inboxes. Just answer the question in a single E-mail. If you want to
>update a single patch, just send that one patch.
Noted. I wasn't sure about it. I'll explicitly ask next time if you want me to
send another one.
>
>If you don't start paying attention to these rules then people are going
>to start ignoring you -- at best! -- and it's going to give the entire
>community a bad reputation.
Even before this, this patch series has been ignored largely. I don't know
how to get attention. All I wanted was either feedback or get it in. And as I
said I've been desparate to get it in. Also as I said, I'll improve.
>
>Please acknowledge that you understand this,
ACKed.
>
>
>- Paul
prev parent reply other threads:[~2025-12-12 18:33 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 17:20 [PATCH v26 00/28] riscv control-flow integrity for usermode Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 01/28] mm: VM_SHADOW_STACK definition for riscv Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 02/28] dt-bindings: riscv: zicfilp and zicfiss in dt-bindings (extensions.yaml) Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 03/28] riscv: zicfiss / zicfilp enumeration Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 04/28] riscv: zicfiss / zicfilp extension csr and bit definitions Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 05/28] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 06/28] riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 07/28] riscv/mm: manufacture shadow stack pte Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 08/28] riscv/mm: teach pte_mkwrite to manufacture shadow stack PTEs Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 09/28] riscv/mm: write protect and shadow stack Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 10/28] riscv/mm: Implement map_shadow_stack() syscall Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 11/28] riscv/shstk: If needed allocate a new shadow stack on clone Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 12/28] riscv: Implements arch agnostic shadow stack prctls Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 13/28] prctl: arch-agnostic prctl for indirect branch tracking Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 14/28] riscv: Implements arch agnostic indirect branch tracking prctls Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 15/28] riscv/traps: Introduce software check exception and uprobe handling Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 16/28] riscv: signal: abstract header saving for setup_sigcontext Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 17/28] riscv/signal: save and restore of shadow stack for signal Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 18/28] riscv/kernel: update __show_regs to print shadow stack register Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 19/28] riscv/ptrace: riscv cfi status and state via ptrace and in core files Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 20/28] riscv/hwprobe: zicfilp / zicfiss enumeration in hwprobe Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 21/28] riscv: kernel command line option to opt out of user cfi Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 22/28] riscv: enable kernel access to shadow stack memory via FWFT sbi call Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 23/28] arch/riscv: compile vdso with landing pad and shadow stack note Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 24/28] arch/riscv: dual vdso creation logic and select vdso based on hw Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 25/28] riscv: create a config for shadow stack and landing pad instr support Deepak Gupta via B4 Relay
2025-12-11 17:20 ` [PATCH v26 26/28] riscv: Documentation for landing pad / indirect branch tracking Deepak Gupta via B4 Relay
2025-12-11 17:21 ` [PATCH v26 27/28] riscv: Documentation for shadow stack on riscv Deepak Gupta via B4 Relay
2025-12-11 17:21 ` [PATCH v26 28/28] kselftest/riscv: kselftest for user mode cfi Deepak Gupta via B4 Relay
2025-12-12 5:50 ` [PATCH v26 00/28] riscv control-flow integrity for usermode patchwork-bot+linux-riscv
2025-12-12 8:15 ` Paul Walmsley
2025-12-12 8:30 ` Paul Walmsley
2025-12-12 18:33 ` Deepak Gupta [this message]
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=aTxf7IGlkGLgHgI2@debug.ba.rivosinc.com \
--to=debug@rivosinc.com \
--cc=Liam.Howlett@oracle.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=alexghiti@rivosinc.com \
--cc=aliceryhl@google.com \
--cc=alistair.francis@wdc.com \
--cc=andreas.korb@aisec.fraunhofer.de \
--cc=andybnac@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=atishp@rivosinc.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=broonie@kernel.org \
--cc=charlie@rivosinc.com \
--cc=cleger@rivosinc.com \
--cc=cmirabil@redhat.com \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=devicetree@vger.kernel.org \
--cc=ebiederm@xmission.com \
--cc=evan@rivosinc.com \
--cc=gary@garyguo.net \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=jim.shu@sifive.com \
--cc=kees@kernel.org \
--cc=kito.cheng@sifive.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@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=lorenzo.stoakes@oracle.com \
--cc=lossin@kernel.org \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=oleg@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=pjw@kernel.org \
--cc=richard.henderson@linaro.org \
--cc=rick.p.edgecombe@intel.com \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=tmgross@umich.edu \
--cc=valentin.haudiquet@canonical.com \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
--cc=zong.li@sifive.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).