Re: [for-next][PATCH 12/16] kprobes: Initialize kprobes at postcore_initcall

[Catalin Marinas]

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@xxxxxxxxxxx>
> wrote:
> > On Tue, 2 Jul 2019 17:50:09 +0100 Mark Rutland
> > <mark.rutland@xxxxxxx> wrote:
> > > On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> > > > Signed-off-by: Masami Hiramatsu <mhiramat@xxxxxxxxxx>
> > > > Signed-off-by: Steven Rostedt (VMware) <rostedt@xxxxxxxxxxx>
> > > > ---
> > > >  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