On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote: > As Ard says, module_alloc() _is_ special, in the sense that the virtual > memory it allocates wants to be close to the kernel text, whereas the > concept of allocating executable memory is broader and doesn't have these > restrictions. So, while I'm in favour of having a text_alloc() interface > that can be used by callers which only require an executable mapping, I'd > much prefer for the module_alloc() code to remain for, err, modules.
So on x86 all those things (kprobes, bpf, ftrace) require that same closeness. An interface like the late vmalloc_exec() will simply not work for us. We recently talked about arm64-kprobes and how you're not doing any of the optimizations and fully rely on the exception return. And I see you're one of the few archs that has bpf_jit_alloc_exec() (also, shouldn't you be using PAGE_KERNEL_EXEC there?). But the BPF core seems to use module_alloc() as a default means of allocating text. So what should this look like? Have a text_alloc() with an argument that indicates where? But then I suppose we also need a means to manage PLT entries. Otherwise I don't exactly see how you're going to call BPF code, or how that BPF stuff is going to call back into its helpers.
