On Tue, 14 Jul 2020 at 12:53, Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> wrote: > > On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote: > > This patch suggests that there are other reasons why conflating > > allocation of module space and allocating text pages for other uses > > is a bad idea, but switching all users to text_alloc() is a step in > > the wrong direction. It would be better to stop using module_alloc() > > in core code except in the module loader, and have a generic > > text_alloc() that can be overridden by the arch if necessary. Note > > that x86 and s390 are the only architectures that use module_alloc() > > in ftrace code. > > This series essentially does this: introduces text_alloc() and > text_memfree(), which have generic implementations in kernel/text.c. > Those can be overriddent by arch specific implementations. > > What you think should be done differently than in my patch set? >
On arm64, module_alloc is only used by the module loader, and so pulling it out and renaming it will cause unused code to be incorporated into the kernel when building without module support, which is the use case you claim to be addressing. Module_alloc has semantics that are intimately tied to the module loader, but over the years, it ended up being (ab)used by other subsystems, which don't require those semantics but just need n pages of vmalloc space with executable permissions. So the correct approach is to make text_alloc() implement just that, generically, and switch bpf etc to use it. Then, only on architectures that need it, override it with an implementation that has the required additional semantics. Refactoring 10+ architectures like this without any regard for how text_alloc() deviates from module_alloc() just creates a lot of churn that others will have to clean up after you.
