On Fri, Apr 26, 2024 at 1:30 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > From: "Mike Rapoport (IBM)" <rppt@xxxxxxxxxx> > > 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) <rppt@xxxxxxxxxx> > Acked-by: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> Acked-by: Song Liu <song@xxxxxxxxxx>
