[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D036FYBQUMIX.L5TL0SUCAO49@kernel.org>
Date: Tue, 26 Mar 2024 00:16:46 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>, <linux-riscv@...ts.infradead.org>
Cc: "Masami Hiramatsu" <mhiramat@...nel.org>, "Paul Walmsley"
<paul.walmsley@...ive.com>, "Palmer Dabbelt" <palmer@...belt.com>, "Albert
Ou" <aou@...s.berkeley.edu>, <linux-kernel@...r.kernel.org>, "Luis
Chamberlain" <mcgrof@...nel.org>, <linux-modules@...r.kernel.org>, "Naveen
N . Rao" <naveen.n.rao@...ux.ibm.com>, "Anil S Keshavamurthy"
<anil.s.keshavamurthy@...el.com>, "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH v5 1/2] kprobes: textmem API
On Tue Mar 26, 2024 at 12:09 AM EET, Jarkko Sakkinen wrote:
> On Mon Mar 25, 2024 at 11:55 PM EET, Jarkko Sakkinen wrote:
> > +#ifdef CONFIG_MODULES
> > if (register_module_notifier(&trace_kprobe_module_nb))
> > return -EINVAL;
> > +#endif /* CONFIG_MODULES */
>
> register_module_notifier() does have "dummy" version but what
> would I pass to it. It makes more mess than it cleans to declare
> also a "dummy" version of trace_kprobe_module_nb.
>
> The callback itself has too tight module subsystem bindings so
> that they could be simply flagged with IS_DEFINED() (or correct
> if I'm mistaken, this the conclusion I've ended up with).
One way to clean that up would be to create trace_kprobe_module.c and
move kernel module specific code over there and then change
kernel/trace/Makefile as follows:
ifeq ($(CONFIG_PERF_EVENTS),y)
obj-y += trace_kprobe.o
obj-$(CONFIG_MODULES) += trace_kprobe_module.o
endif
and define trace_kprobe_module_init() or similar to do all the dance
with notifiers etc.
This crossed my mind but did not want to do it without feedback.
BR, Jarkko
Powered by blists - more mailing lists