On Tue, 4 Jun 2019 05:06:29 -0400 Steven Rostedt <[email protected]> wrote:
> On Mon, 3 Jun 2019 22:04:42 +0900 > Masami Hiramatsu <[email protected]> wrote: > > > Since arm64 kernel initializes breakpoint trap vector in arch_initcall(), > > initializing kprobe (and run smoke test) in postcore_initcall() causes > > a kernel panic. > > > > To fix this issue, move the kprobe initialization in subsys_initcall() > > (which is called right afer the arch_initcall). > > > > In-kernel kprobe users (ftrace and bpf) are using fs_initcall() which is > > called after subsys_initcall(), so this shouldn't cause more problem. > > > > Reported-by: Anders Roxell <[email protected]> > > Fixes: b5f8b32c93b2 ("kprobes: Initialize kprobes at postcore_initcall") > > Hi Masami, > > Is this really a fix, or is this just needed to add kprobes to the command > line? Hi Steve, Yes, this is a real fix, not related to the kprobes command line feature. First of all, the problem was that kprobes(module_init) was initialized later than trace_kprobe(fs_initcall). the commit b5f8b32c93b2 is to solve it. But I missed that the break-point hander initialization can be done in arch_initcall on some archs. This is fixing that bug. Thank you, > > -- Steve > > > > Signed-off-by: Masami Hiramatsu <[email protected]> > > --- > > kernel/kprobes.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > > index 54aaaad00a47..5471efbeb937 100644 > > --- a/kernel/kprobes.c > > +++ b/kernel/kprobes.c > > @@ -2289,7 +2289,7 @@ static int __init init_kprobes(void) > > init_test_probes(); > > return err; > > } > > -postcore_initcall(init_kprobes); > > +subsys_initcall(init_kprobes); > > > > #ifdef CONFIG_DEBUG_FS > > static void report_probe(struct seq_file *pi, struct kprobe *p, > -- Masami Hiramatsu <[email protected]>
