Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper
From: Jarkko Sakkinen <hidden>
Date: 2020-07-14 19:30:09
Also in:
linux-riscv
On Tue, Jul 14, 2020 at 03:56:52PM +0200, Jessica Yu wrote:
quoted hunk ↗ jump to hunk
+++ Jarkko Sakkinen [14/07/20 12:45 +0300]:quoted
Rename module_alloc() to text_alloc() and module_memfree() to text_memfree(), and move them to kernel/text.c, which is unconditionally compiled to the kernel proper. This allows kprobes, ftrace and bpf to allocate space for executable code without requiring to compile the modules support (CONFIG_MODULES=y) in. Cc: Andi Kleen <redacted> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Jarkko Sakkinen <redacted>As Ard and Will have already explained, the major issue I'm having with this is that we're taking module_alloc(), an allocator that was originally specific to module loading, and turning it into a generic interface to be used by other subsystems. You're pulling in all the module loading semantics that vary by architecture and expecting it to work as a generic text allocator. I'm not against the existence of a generic text_alloc() but I would very much rather that module_alloc() be left alone to the module loader and instead work on introducing a *separate* generic text_alloc() interface that would work for its intended users (kprobes, bpf, etc) and have existing users of module_alloc() switch to that instead. Jessica
This is kind of patch set where you do not have any other chances than to get it wrong in the first time, so I just did something that flys in my environment. At the same time I believe that taking the bound out of tracing and module loading is a generally accepted idea. I'm refining the next version with CONFIG_HAS_TEXT_ALLOC, which I explained in more details in my earlier response to this thread. /Jarkko