On Tue, 14 Jul 2020 at 05:04, Steven Rostedt <rost...@goodmis.org> wrote: > > On Mon, 13 Jul 2020 22:49:48 +0300 > Ard Biesheuvel <a...@kernel.org> wrote: > > > On arm64, we no longer use module_alloc for bpf or kprobes, to avoid > > wasting va space on code that does not need to be loaded close to the > > kernel. Also, module_alloc() allocates kasan shadow, which is > > unnecessary for kprobes or bpf programs, which don't have kasan > > instrumentation. > > > > 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. > > > > Please have a look at alloc_insn_page() or bpf_jit_alloc_exec() in the > > arm64 tree to see what I mean. > > Hmm, so you have another method for allocating memory for trampolines? > (I haven't looked at those functions you pointed out, out of sheer > laziness ;-) > > It would be nice to implement the trampoline optimization in arm, which > x86 has (see arch_ftrace_update_trampoline() and > arch_ftrace_trampoline_func()). > > It helps when you have two different callbacks for different functions > (like having live patching enabled and function tracing enabled, or > kprobes using ftrace). Each callback will get its own allocated > trampoline to jump to instead of jumping to the a trampoline that calls > a looping function that tests to see which callback wants to be called > by the traced function. >
So in what sense are ftrace trampolines like kernel modules, apart from the fact that they are executable pages that live in the vmalloc space?
