[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