Le 09/06/2022 à 14:57, Jarkko Sakkinen a écrit : > On Thu, Jun 09, 2022 at 08:30:12AM +0000, Christophe Leroy wrote: >> >> >> Le 08/06/2022 à 01:59, Jarkko Sakkinen a écrit : >>> [You don't often get email from jar...@profian.com. Learn why this is >>> important at https://aka.ms/LearnAboutSenderIdentification ] >>> >>> 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. >> >> Nice idea, could also be nice to have BPF without MODULES. > > Yeah, for sure. You have to start from somewhere :-) I'd guess this > a step forward also for BPF. > >>> >>> 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. >> >> Nice, but that's not enough. You have to audit every peace of code that >> depends on CONFIG_MODULES and see if it needs to be activated for your >> case as well. For instance some powerpc configurations don't honor exec >> page faults on kernel pages when CONFIG_MODULES is not selected. > > Thanks for pointing this out. With "every peace of code" you probably > are referring to the 13 arch-folders, which support kprobes in the first > place (just checking)?
In a way yes, I was mainly thinking about the dozen of places in arch/powerpc/ to begin with. And also to check the 30 places with CONFIG_MODULES in includes/ directory which contains things that may be used by architectures.