Hi Steve, On Wed, 3 Jul 2019 10:02:05 -0400 Steven Rostedt <[email protected]> wrote:
> On Tue, 2 Jul 2019 17:50:09 +0100 > Mark Rutland <[email protected]> wrote: > > > On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote: > > > From: Masami Hiramatsu <[email protected]> > > > > > > Initialize kprobes at postcore_initcall level instead of module_init > > > since kprobes is not a module, and it depends on only subsystems > > > initialized in core_initcall. > > > This will allow ftrace kprobe event to add new events when it is > > > initializing because ftrace kprobe event is initialized at > > > later initcall level. > > > > > > Link: > > > http://lkml.kernel.org/r/155851394736.15728.13626739508905120098.stgit@devnote2 > > > > > > Signed-off-by: Masami Hiramatsu <[email protected]> > > > Signed-off-by: Steven Rostedt (VMware) <[email protected]> > > > --- > > > kernel/kprobes.c | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > > > index b1ea30a5540e..54aaaad00a47 100644 > > > --- a/kernel/kprobes.c > > > +++ b/kernel/kprobes.c > > > @@ -2289,6 +2289,7 @@ static int __init init_kprobes(void) > > > init_test_probes(); > > > return err; > > > } > > > +postcore_initcall(init_kprobes); > > > > As a heads-up, this is causing boot-time failures on arm64. > > Thanks for the report. > > > > > On arm64 kprobes depends on the BRK handler we register in > > debug_traps_init(), which is an arch_initcall. > > > > As of this change, init_krprobes() calls init_test_probes() before > > that's registered, so we end up hitting a BRK before we can handle it. > > > > Would something like this help? > > -- Steve > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > index 5471efbeb937..0ca6f53c8505 100644 > --- a/kernel/kprobes.c > +++ b/kernel/kprobes.c > @@ -2235,6 +2235,8 @@ static struct notifier_block kprobe_module_nb = { > extern unsigned long __start_kprobe_blacklist[]; > extern unsigned long __stop_kprobe_blacklist[]; > > +static bool run_kprobe_tests __initdata; > + > static int __init init_kprobes(void) > { > int i, err = 0; > @@ -2286,11 +2288,18 @@ static int __init init_kprobes(void) > kprobes_initialized = (err == 0); > > if (!err) > - init_test_probes(); > + run_kprobe_tests = true; > return err; > } > subsys_initcall(init_kprobes); Just out of curious, if arm64's handler code initialized in arch_initcall, why this subsys_initcall() function causes a problem? This is actually related to my boot-time tracing series, so I would like fix this issue without this patch. Thank you, > > +static int __init run_init_test_probes(void) > +{ > + if (run_kprobe_tests) > + init_test_probes(); > +} > +module_init(run_init_test_probes); > + > #ifdef CONFIG_DEBUG_FS > static void report_probe(struct seq_file *pi, struct kprobe *p, > const char *sym, int offset, char *modname, struct kprobe *pp) > -- Masami Hiramatsu <[email protected]>
