[PATCH] arm64: Fix early single-stepping
Masami Hiramatsu
mhiramat at kernel.org
Mon Oct 26 20:48:06 EDT 2020
On Mon, 26 Oct 2020 17:38:37 +0000
Will Deacon <will at kernel.org> wrote:
> On Mon, Oct 26, 2020 at 06:29:09PM +0100, Jean-Philippe Brucker wrote:
> > To use debug features such as single-step, the OS lock must be unlocked
> > in the debug registers. Currently this is done in postcore_initcall
> > which is now too late.
> >
> > Commit 36dadef23fcc ("kprobes: Init kprobes in early_initcall") enabled
> > using kprobes from early_initcall, when OS lock is still locked. So when
> > kprobe attempts to single-step a patched instruction, instead of
> > trapping, execution continues until it throws an undef exception:
> >
> > [ 0.064233] Kprobe smoke test: started
> > [ 0.151133] ------------[ cut here ]------------
> > [ 0.151458] kernel BUG at arch/arm64/kernel/traps.c:406!
> > [ 0.151812] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> > ...
> > [ 0.162689] Call trace:
> > [ 0.163014] do_undefinstr+0x1d4/0x1f4
> > [ 0.163336] el1_sync_handler+0xbc/0x140
> > [ 0.163839] el1_sync+0x80/0x100
> > [ 0.164154] 0xffffffc01001d004
> > [ 0.164527] init_kprobes+0x13c/0x154
> > [ 0.164968] do_one_initcall+0x54/0x2e0
> > [ 0.165322] kernel_init_freeable+0xf4/0x258
> > [ 0.165783] kernel_init+0x20/0x12c
> > [ 0.166117] ret_from_fork+0x10/0x30
> > [ 0.166595] Code: 97ffff53 a9425bf5 17ffff9b f9001bf7 (d4210000)
> > [ 0.167084] ---[ end trace 36778fdf576e9a79 ]---
> >
> > To fix this, unlock the OS lock as early as possible. Do it in
> > traps_init() for CPU0, since KGDB wants to use single-step from that
> > point on according to commit b322c65f8ca3 ("arm64: Call
> > debug_traps_init() from trap_init() to help early kgdb").
> > For secondary CPUs, setup the CPU hotplug handler at early_initcall.
Oops, thanks for the fix! I missed it.
> Hmm, does this mean we end up setting MDSCR_EL1.KDE before we've reset the
> hardware breakpoint/watchpoint registers? Why do we need kprobes so early?
This is for boot-time tracing. To enable kprobes events in core_initcall(),
we need to enable kprobes itself in early_initcall().(or early_initcall_sync())
With this, we can trace postcore functions with kprobes(it includes some platform
initializations), which is making boot-time ftrace more useful.
For example, we can trace function-calls in specific code area as I posted
an example;
https://lore.kernel.org/linux-doc/159887792384.1330989.5993224243767476896.stgit@devnote2/
So this expands the feature to the earlier stages.
Thank you,
--
Masami Hiramatsu <mhiramat at kernel.org>
More information about the linux-arm-kernel
mailing list