[RFC PATCH 0/3] arm64: Implement reliable stack trace

Mark Brown broonie at kernel.org
Thu Oct 15 11:49:51 EDT 2020


On Thu, Oct 15, 2020 at 03:16:12PM +0100, Mark Rutland wrote:
> On Thu, Oct 15, 2020 at 03:39:37PM +0200, Miroslav Benes wrote:

> > I'll just copy an excerpt from my notes about the required guarantees. 
> > Written by Josh (CCed, he has better idea about the problem than me 
> > anyway).

> > It also needs to:
> > - detect preemption / page fault frames and return an error
> > - only return success if it reaches the end of the task stack; for user
> >   tasks, that means the syscall barrier; for kthreads/idle tasks, that
> >   means finding a defined thread entry point
> > - make sure it can't get into a recursive loop
> > - make sure each return address is a valid text address
> > - properly detect generated code hacks like function graph tracing and
> >   kretprobes
> > "

> It would be great if we could put something like the above into the
> kernel tree, either under Documentation/ or in a comment somewhere for
> the reliable stacktrace functions.

Yes, please - the expecations are quite hard to follow at the minute,
implementing it involves quite a bit of guesswork and cargo culting to
figure out what the APIs are supposed to do.

> AFAICT, existing architectures don't always handle all of the above in
> arch_stack_walk_reliable(). For example, it looks like x86 assumes
> unwiding through exceptions is reliable for !CONFIG_FRAME_POINTER, but I
> think this might not always be true.

I certainly wouldn't have inferred the list from what's there :/  The
searching for a defined thread entry point for example isn't entirely
visible in the implementations.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20201015/6d33de16/attachment.sig>


More information about the linux-arm-kernel mailing list