Re: Getting user-space stack backtraces in more probe contexts

[Roland McGrath <roland at redhat dot com>]

> I don't see a strong connection between the unwind-data-preload vs.
> two-phase unwinding.  We could attempt to access user .eh_frame data
> from our current context too.  We could also attempt to page that stuff
> in ahead of time (with the proviso that the kernel could throw it back
> out again).

The point is that at the safe point you can rely entirely on normal paging
of the user text and so not become unreliable under memory pressure.  As
long as you're avoiding real paging, then anyone wanting sure reliability
will need the prepacking or else a pre-mlock'ing of all the user .eh_frame
pages, which has roughly equivalent precommitted-RAM constraints to
prepacking.  Normal user paging is the only thing that will ever be
entirely reasonable for scripts that could be entirely unprivileged and
still work as reliably as the user data makes possible.

> OK, I guess we'd then have to be able to know when we're in one of
> these 'complete information' probe contexts.

To a first approximation syscall_get_nr(task, task_pt_regs(task)) < 0 tells
you.  That can actually also be telling you that it's a syscall tracing
stop for a bogus syscall entry with too many bits set in the syscall number
register.  The only place you could be other than the syscall tracing stop
is an in-kernel interrupt somewhere on the entry path (irq or preemption).
In that case, the task_pt_regs(current) state can be even more
partial--only the PC and SP are stored before interrupts are enabled.  
(The kernel assembly CFI should walk you through all such states fine, but
that's not the point here.)


Thanks,
Roland