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
Reply to
Josh Poimboeuf, 2025-07-18
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.
Thread (42 messages) 42 messages, 4 authors, last reply 2025-08-01
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help