On Fri, Apr 19, 2024 at 03:59:40PM +0000, Christophe Leroy wrote: > > > Le 19/04/2024 à 17:49, Mike Rapoport a écrit : > > Hi Masami, > > > > On Thu, Apr 18, 2024 at 06:16:15AM +0900, Masami Hiramatsu wrote: > >> Hi Mike, > >> > >> On Thu, 11 Apr 2024 19:00:50 +0300 > >> Mike Rapoport <r...@kernel.org> wrote: > >> > >>> From: "Mike Rapoport (IBM)" <r...@kernel.org> > >>> > >>> kprobes depended on CONFIG_MODULES because it has to allocate memory for > >>> code. > >>> > >>> Since code allocations are now implemented with execmem, kprobes can be > >>> enabled in non-modular kernels. > >>> > >>> Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside > >>> modules, make CONFIG_KPROBES select CONFIG_EXECMEM and drop the > >>> dependency of CONFIG_KPROBES on CONFIG_MODULES. > >> > >> Thanks for this work, but this conflicts with the latest fix in v6.9-rc4. > >> Also, can you use IS_ENABLED(CONFIG_MODULES) instead of #ifdefs in > >> function body? We have enough dummy functions for that, so it should > >> not make a problem. > > > > The code in check_kprobe_address_safe() that gets the module and checks for > > __init functions does not compile with IS_ENABLED(CONFIG_MODULES). > > I can pull it out to a helper or leave #ifdef in the function body, > > whichever you prefer. > > As far as I can see, the only problem is MODULE_STATE_COMING. > Can we move 'enum module_state' out of #ifdef CONFIG_MODULES in module.h ?
There's dereference of 'struct module' there: (*probed_mod)->state != MODULE_STATE_COMING) { ... } so moving out 'enum module_state' won't be enough. > > > >> -- > >> Masami Hiramatsu > > -- Sincerely yours, Mike.