[PATCH v2 09/12] ARM: kprobes: treat R7 as the frame pointer register in Thumb2 builds

[Masami Hiramatsu]

On Tue, 1 Feb 2022 15:05:25 +0100
Ard Biesheuvel <ardb at kernel.org> wrote:

> On Tue, 1 Feb 2022 at 14:18, Masami Hiramatsu <mhiramat at kernel.org> wrote:
> >
> > On Mon, 31 Jan 2022 18:03:44 +0100
> > Ard Biesheuvel <ardb at kernel.org> wrote:
> >
> > > Thumb2 code uses R7 as the frame pointer rather than R11, because the
> > > opcodes to access it are generally shorter.
> > >
> > > This means that there are cases where we cannot simply add it to the
> > > clobber list of an asm() block, but need to preserve/restore it
> > > explicitly, or the compiler may complain in some cases (e.g., Clang
> > > builds with ftrace enabled).
> > >
> > > Since R11 is not special in that case, clobber it instead, and use it to
> > > preserve/restore the value of R7.
> >
> > Thanks Ard for fixing thumb2 issue!
> 
> No problem. Although I'm still not 100% sure we can simply
> preserve/restore the frame pointer like that. What is the expected
> result when an exception occurs in the kprobes emulation code?

What kind of exception would you mean? If it is a synchronous
exception and can return to where the exception happens, the
all registers must be restored. So as long as it is restored
it is OK to me.

> The main problem is that with unwind info unwinding, the stack pointer
> and the frame pointer need to be mutually in sync, and with the
> kprobes stack frames in the middle, this is no longer correct - the
> emulated code is executed with the frame pointer value that was
> captured when the probe was hit, by the stack has a couple of frames
> added.
> 
> > BTW, have you build the kernel with CONFIG_KPROBES_SANITY_TEST=y?
> > It should check the backtrace from kprobe and kretprobe at boot time.
> >
> 
> Just checked, and those work fine.

Thank you for testing!

Reviewed-by: Masami Hiramatsu <mhiramat at kernel.org>

Thank you,

-- 
Masami Hiramatsu <mhiramat at kernel.org>