Messages in this thread | | | Date | Wed, 22 May 2019 16:30:21 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH 0/2] Enable new kprobe event at boot |
| |
On Wed, 22 May 2019 00:39:32 +0900 Masami Hiramatsu <mhiramat@kernel.org> 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(). 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.
Thank you,
-- Masami Hiramatsu <mhiramat@kernel.org>
| |