On Tue, Jul 14, 2020 at 03:56:52PM +0200, Jessica Yu wrote: > +++ Jarkko Sakkinen [14/07/20 12:45 +0300]: > > 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 <a...@linux.intel.com> > > Suggested-by: Peter Zijlstra <pet...@infradead.org> > > Signed-off-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> > > 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
