On Fri, Apr 26, 2024 at 1:30 AM Mike Rapoport <r...@kernel.org> wrote: > > From: "Mike Rapoport (IBM)" <r...@kernel.org> > > module_alloc() is used everywhere as a mean to allocate memory for code. > > Beside being semantically wrong, this unnecessarily ties all subsystems > that need to allocate code, such as ftrace, kprobes and BPF to modules and > puts the burden of code allocation to the modules code. > > Several architectures override module_alloc() because of various > constraints where the executable memory can be located and this causes > additional obstacles for improvements of code allocation. > > Start splitting code allocation from modules by introducing execmem_alloc() > and execmem_free() APIs. > > Initially, execmem_alloc() is a wrapper for module_alloc() and > execmem_free() is a replacement of module_memfree() to allow updating all > call sites to use the new APIs. > > Since architectures define different restrictions on placement, > permissions, alignment and other parameters for memory that can be used by > different subsystems that allocate executable memory, execmem_alloc() takes > a type argument, that will be used to identify the calling subsystem and to > allow architectures define parameters for ranges suitable for that > subsystem. > > No functional changes. > > Signed-off-by: Mike Rapoport (IBM) <r...@kernel.org> > Acked-by: Masami Hiramatsu (Google) <mhira...@kernel.org>
Acked-by: Song Liu <s...@kernel.org>
