On Wed, 22 May 2019 16:30:21 +0900 Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > On Wed, 22 May 2019 00:39:32 +0900 > Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > Perhaps we could enable kprobes at early init? > > > > It should be possible, I will try to find what blocks it. I guess after we > > switch early_text_poke() to text_poke(), we can use kprobes on x86. But > > for other archs, I need to investigate more. > > OK, I just follow the kernel init related to kprobes > > start_kernel() > -> trace_init() > -> rcu_init_nohz() > -> perf_event_init() > -> arch_call_rest_init() > -> rest_init() > -> rcu_scheduler_starting() > -> kernel_thread(kernel_init) > kernel_init() > -> kernel_init_freeable() > -> wait_for_completion(&kthreadd_done); > -> workqueue_init() > -> smp_init() > -> do_basic_setup() > -> do_initcalls() > -> do_initcall_level() > (in subsys-level) > -> init_kprobes() > > Since optprobe uses workqueue, we can not move it before workqueue_init(). > (but maybe we can disable it in early stage) > Also, since kprobes depends on rcu, I guess we can not move it before > rcu_scheduler_starting(). It seems rcu is not initialized yet at this point. It is initialized fully at core_initcall. > for kretprobe, we need to get the possible cpus, we need a fix if we move > it before before smp_init(). > However, there is no reason we need to run it in subsys level. We can > move init_kprobes() in core or pure level safely. Also, I missed ftrace (function tracer) is initialized at core_initcall(). So we can move init_kprobes() at postcore_initcall() safely. Thank you, -- Masami Hiramatsu <mhiramat@xxxxxxxxxx>
