From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "Jan Sebastian Götte" <linux@jaseg.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <baoquan.he@linux.dev>,
Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Dave Young <ruirui.yang@linux.dev>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <brendan.jackman@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>,
Benjamin Marzinski <bmarzins@redhat.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Mimi Zohar <zohar@linux.ibm.com>,
David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
"Liam R. Howlett" <liam@infradead.org>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
Rik van Riel <riel@surriel.com>, Harry Yoo <harry@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Peter Xu <peterx@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Eric Biggers <ebiggers@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, kexec@lists.infradead.org,
driver-core@lists.linux.dev, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org, dm-devel@lists.linux.dev,
linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org,
keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS)
Date: Mon, 28 Sep 2026 18:49:51 +0100 [thread overview]
Message-ID: <arqli0H0v5qPG22z@gremlin> (raw)
In-Reply-To: <20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de>
On Mon, Sep 28, 2026 at 07:17:48PM +0200, Jan Sebastian Götte wrote:
> I'm using linux on an embedded target in a Hardware Security Module-like
> application. One requirement is that I want the system to be able to
> quickly erase its memory when it detects physical tampering. I'm
> approaching that by using kdump to load into a small payload that
> instead of dumping RAM, erases RAM frmo start to end. However, writing
> all of RAM, especially on an embedded target, is rather slow. For this
> reason, I propose a new crash_memaction mechanism that lets the old
> kernel indicate marked memory areas to the kdump kernel at page
> granularity.
Sorry this all seems really invasive for what seems to be a very specific
use case.
In general, with big changes like this, you should send the series as an
RFC.
Please send any future revisions of this as an RFC.
The bar for a new VMA flag, a new madvise() flag, etc. is really quite
high, and I've already noticed what looks like quite buggy code glancing
through.
And again, I really don't think your case sounds all that compelling for
general users, given how invasive the changes are, so I strongly suggest
you rethink your approach.
In any case, as a newcomer to mm, we really ask that people start with
smaller changes and build up gradually, a change like this really should
only be done by somebody with an established reputation in the kernel.
In general re: AI-generated code see
https://docs.kernel.org/process/generated-content.html
If tools permit you to generate a contribution automatically, expect
additional scrutiny in proportion to how much of it was generated.
As with the output of any tooling, the result may be incorrect or
inappropriate. You are expected to understand and to be able to defend
everything you submit. If you are unable to do so, then do not submit the
resulting changes.
If you do so anyway, maintainers are entitled to reject your series without
detailed review.
Thanks!
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-09-28 17:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 17:17 Jan Sebastian Götte
2026-09-28 17:17 ` [PATCH v3 01/12] kexec: Add a crash memaction registry Jan Sebastian Götte
2026-09-28 17:36 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 02/12] lib, kexec: Add a secret pool for key material Jan Sebastian Götte
2026-09-28 17:36 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 03/12] mm: Wire up the crash memaction registry Jan Sebastian Götte
2026-09-28 17:38 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 04/12] arm64: Enable " Jan Sebastian Götte
2026-09-28 17:35 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 05/12] dm crypt: Allocate key material from the secret pool Jan Sebastian Götte
2026-09-28 17:33 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 06/12] crypto: api - Allocate tfms " Jan Sebastian Götte
2026-09-28 17:32 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 07/12] security/keys: Allocate key payloads " Jan Sebastian Götte
2026-09-28 17:32 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 08/12] mm: Add VM_CRASH_MARK Jan Sebastian Götte
2026-09-28 17:34 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 09/12] mm/rmap: Mark folios mapped into crash_memaction-marked VMAs Jan Sebastian Götte
2026-09-28 17:41 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 10/12] mm/madvise: Add MADV_CRASH_SECRET, MADV_CRASH_CACHE and MADV_CRASH_RESET Jan Sebastian Götte
2026-09-28 17:35 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 11/12] Documentation/mm: Document the crash memaction registry Jan Sebastian Götte
2026-09-28 17:31 ` sashiko-bot
2026-09-28 17:18 ` [PATCH v3 12/12] kexec: Expose the crash memaction bitmap in debugfs Jan Sebastian Götte
2026-09-28 17:38 ` sashiko-bot
2026-09-28 19:19 ` Randy Dunlap
2026-09-28 17:49 ` Lorenzo Stoakes (ARM) [this message]
2026-09-28 18:58 ` [PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS) David Hildenbrand (Arm)
2026-09-28 19:02 ` David Hildenbrand (Arm)
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=arqli0H0v5qPG22z@gremlin \
--to=ljs@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=bmarzins@redhat.com \
--cc=brendan.jackman@linux.dev \
--cc=byungchul@sk.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=davem@davemloft.net \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=dhowells@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=driver-core@lists.linux.dev \
--cc=ebiggers@kernel.org \
--cc=gourry@gourry.net \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=jannh@google.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux@jaseg.de \
--cc=mark.rutland@arm.com \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=mpatocka@redhat.com \
--cc=muchun.song@linux.dev \
--cc=nico.pache@linux.dev \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=paul@paul-moore.com \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=pratyush@kernel.org \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=riel@surriel.com \
--cc=robh@kernel.org \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=saravanak@kernel.org \
--cc=serge@hallyn.com \
--cc=skhan@linuxfoundation.org \
--cc=snitzer@kernel.org \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=will@kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
--cc=zohar@linux.ibm.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
all inboxes | Powered by JetHome®