Thread (42 messages) 42 messages, 4 authors, 2025-08-01

Re: [RFC PATCH v1 12/16] unwind_user/backchain: Introduce back chain user space unwinding

From: Heiko Carstens <hca@linux.ibm.com>
Date: 2025-08-01 12:38:08
Also in: bpf, lkml

On Thu, Jul 17, 2025 at 10:19:54PM -0700, Josh Poimboeuf wrote:
On Thu, Jul 17, 2025 at 02:20:12PM +0200, Jens Remus wrote:
quoted
quoted
Also, if distros aren't even compiling with -mbackchain, I wonder if we
can just not do this altogether :-)
My original intent was to use unwind user's for_each_user_frame() to
replace the exiting stack tracing logic in arch_stack_walk_user_common()
in arch/s390/kernel/stacktrace.c, which currently supports backchain.
Given that for_each_user_frame() was made private in the latest unwind
user series version hinders me.  The use was also low, because the
currentl arch_stack_walk_user_common() implementation does not support
page faults, so that the attempt to use unwind user sframe would always
fail and fallback to unwind user backchain.  My hope was that somebody
with more Kernel skills could give me a few hints at how it could be
made to support deferred unwind. :-)
I believe stack_trace_save_user() is only used by ftrace, and that will
no longer be needed once ftrace starts using unwind_user.

Maybe Heiko knows if that backchain user stacktrace code has any users?

If distros aren't building with -mbackchain, maybe backchain support can
be considered obsoleted by sframe, and we can get away with not
implementing it.
I guess that's a valid option. I know only of some special cases where
users compile everything on their own with -mbackchain to make this
work on a per-case basis. It shouldn't cause to much pain for them to
switch to sframe, as soon as that is available.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help