lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 9 Jul 2019 21:30:49 +0900 From: Masami Hiramatsu <mhiramat@...nel.org> To: Steven Rostedt <rostedt@...dmis.org> Cc: Mark Rutland <mark.rutland@....com>, linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, Masami Hiramatsu <mhiramat@...nel.org>, Catalin Marinas <catalin.marinas@....com> Subject: Re: [for-next][PATCH 12/16] kprobes: Initialize kprobes at postcore_initcall Hi Steve, On Wed, 3 Jul 2019 10:02:05 -0400 Steven Rostedt <rostedt@...dmis.org> wrote: > On Tue, 2 Jul 2019 17:50:09 +0100 > Mark Rutland <mark.rutland@....com> wrote: > > > On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote: > > > From: Masami Hiramatsu <mhiramat@...nel.org> > > > > > > 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 <mhiramat@...nel.org> > > > Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.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); > > > > 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 <mhiramat@...nel.org>
Powered by blists - more mailing lists