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

[Steven Rostedt]

On Wed, 3 Jul 2019 15:08:32 +0100
Catalin Marinas <catalin.marinas@xxxxxxx> wrote:

 
> > -- 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);
> >  
> > +static int __init run_init_test_probes(void)
> > +{
> > +	if (run_kprobe_tests)
> > +		init_test_probes();  
> 
> A return 0 here.
> 
> > +}
> > +module_init(run_init_test_probes);  
> 
> This does the trick. I prefer your fix as it leaves the arch code
> unchanged. In case you need it:

And I actually think yours is better for the opposite reason ;-)

I agree with Masami, that the selftest actually caught a bug here. I
think the arch code may need to change as the purpose of Masami's
changes was to enable kprobes earlier in boot. The selftest failing
means that an early kprobe will fail too.

-- Steve


> 
> Tested-by: Catalin Marinas <catalin.marinas@xxxxxxx>
> 
> Thanks.
>