On Wed, Jun 08, 2022 at 06:27:51PM +0200, Ard Biesheuvel wrote: > Hello Jarkko, > > On Wed, 8 Jun 2022 at 02:02, Jarkko Sakkinen <jarkko@xxxxxxxxxxx> wrote: > > > > Tracing with kprobes while running a monolithic kernel is currently > > impossible because CONFIG_KPROBES is dependent of CONFIG_MODULES. This > > dependency is a result of kprobes code using the module allocator for the > > trampoline code. > > > > Detaching kprobes from modules helps to squeeze down the user space, > > e.g. when developing new core kernel features, while still having all > > the nice tracing capabilities. > > > > For kernel/ and arch/*, move module_alloc() and module_memfree() to > > module_alloc.c, and compile as part of vmlinux when either CONFIG_MODULES > > or CONFIG_KPROBES is enabled. In addition, flag kernel module specific > > code with CONFIG_MODULES. > > > > As the result, kprobes can be used with a monolithic kernel. > > I think I may have mentioned this the previous time as well, but I > don't think this is the right approach. OK, I apologize for my ignorance. It's been a while. > Kprobes uses alloc_insn_page() to allocate executable memory, but the > requirements for this memory are radically different compared to > loadable modules, which need to be within an arch-specific distance of > the core kernel, need KASAN backing etc etc. > > This is why arm64, for instance, does not implement alloc_insn_page() > in terms of module_alloc() [and likely does not belong in this patch > for that reason] > > Is there any reason kprobes cannot simply use vmalloc()? All arch's, except nios2 use vmalloc() in the end for module_alloc(). nios2 uses kmalloc() for the reasons that I'm not aware of, but it does not support kprobes in the first place. Based on this, I think that could work out just fine. I could cope with that. BR, Jarkko
