On Tue, Jul 14, 2020 at 01:17:22PM +0300, Ard Biesheuvel wrote: > > 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.
It certainly does not cause the full module loader to be bundle, only the allocator. > 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. Using generic text_alloc() in kernel/kprobes.c would make it behave differently in arch's that reimplement module_alloc(). That's the main driver for my approach. /Jarkko
