Messages in this thread | | | Date | Mon, 22 Jul 2019 13:34:37 +0100 | From | Catalin Marinas <> | Subject | Re: [for-next][PATCH 12/16] kprobes: Initialize kprobes at postcore_initcall |
| |
On Tue, Jul 09, 2019 at 09:30:49PM +0900, Masami Hiramatsu wrote: > On Wed, 3 Jul 2019 10:02:05 -0400 Steven Rostedt <rostedt@goodmis.org> > wrote: > > On Tue, 2 Jul 2019 17:50:09 +0100 Mark Rutland > > <mark.rutland@arm.com> wrote: > > > On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote: > > > > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> > > > > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> > > > > --- > > > > 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); [...] > > > 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. [...] > > 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?
It doesn't but patch 12/16 in this series changes it to postcore_initcall().
-- Catalin
| |