[PATCH v4 2/3] arm64: stacktrace: Relax frame record alignment requirement to 8 bytes

[Peter Collingbourne]

On Thu, May 13, 2021 at 2:16 AM Mark Rutland <mark.rutland at arm.com> wrote:
>
> Hi Peter,
>
> On Wed, May 12, 2021 at 07:27:08PM -0700, Peter Collingbourne wrote:
> > The AAPCS places no requirements on the alignment of the frame
> > record. In theory it could be placed anywhere, although it seems
> > sensible to require it to be aligned to 8 bytes. With an upcoming
> > enhancement to tag-based KASAN Clang will begin creating frame records
> > located at an address that is only aligned to 8 bytes. Accommodate
> > such frame records in the stack unwinding code.
> >
> > As pointed out by Mark Rutland, the userspace stack unwinding code
> > has the same problem, so fix it there as well.
> >
> > Signed-off-by: Peter Collingbourne <pcc at google.com>
> > Link: https://linux-review.googlesource.com/id/Ia22c375230e67ca055e9e4bb639383567f7ad268
> > Acked-by: Andrey Konovalov <andreyknvl at gmail.com>
> > Reviewed-by: Mark Rutland <mark.rutland at arm.com>
> > Tested-by: Mark Rutland <mark.rutland at arm.com>
> > ---
> > v4:
> > - rebase to 5.13rc1
>
> I think the rebase went slightly wrong; note below.
>
> > diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> > index 2fecbf152e80..020e575e5cd3 100644
> > --- a/arch/arm64/kernel/stacktrace.c
> > +++ b/arch/arm64/kernel/stacktrace.c
> > @@ -68,7 +68,11 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
> >       unsigned long fp = frame->fp;
> >       struct stack_info info;
> >
> > -     if (fp & 0xf)
> > +     /* Terminal record; nothing to unwind */
> > +     if (!fp)
> > +             return -ENOENT;
> > +
> > +     if (fp & 0x7)
> >               return -EINVAL;
>
> The terminal record check got moved later in the function by commit:
>
>   8533d5bfad41e74b ("arm64: stacktrace: restore terminal records")
>
> ... so this patch shouldn't re-add it. With that gone (and this just
> changing the alignemnt check), this looks good to me.

Thanks, fixed in v5.

Peter