On Thu, Jun 1, 2023 at 3:13 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > From: "Mike Rapoport (IBM)" <rppt@xxxxxxxxxx> > > Hi, > > module_alloc() is used everywhere as a mean to allocate memory for code. > > Beside being semantically wrong, this unnecessarily ties all subsystmes > 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. > > This set splits code allocation from modules by introducing > jit_text_alloc(), jit_data_alloc() and jit_free() APIs, replaces call > sites of module_alloc() and module_memfree() with the new APIs and > implements core text and related allocation in a central place. > > Instead of architecture specific overrides for module_alloc(), the > architectures that require non-default behaviour for text allocation must > fill jit_alloc_params structure and implement jit_alloc_arch_params() that > returns a pointer to that structure. If an architecture does not implement > jit_alloc_arch_params(), the defaults compatible with the current > modules::module_alloc() are used. > > The new jitalloc infrastructure allows decoupling of kprobes and ftrace > from modules, and most importantly it enables ROX allocations for > executable memory. This set does look cleaner than my version [1]. However, this is partially because this set only separates text and data; while [1] also separates rw data, ro data, and ro_after_init data. We need such separation to fully cover module usage, and to remove VM_FLUSH_RESET_PERMS. Once we add these logic to this set, the two versions will look similar. OTOH, I do like the fact this version enables kprobes (and potentially ftrace and bpf) without CONFIG_MODULES. And mm/ seems a better home for the logic. That being said, besides comments in a few patches, this version looks good to me. With the fix I suggested for patch 12/13, it passed my tests on x86_64 with modules, kprobes, ftrace, and BPF. If we decided to ship this version, I would appreciate it if I could get more credit for my work in [1] and research work before that. Thanks, Song [1] https://lore.kernel.org/lkml/20230526051529.3387103-1-song@xxxxxxxxxx/
