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
