On Fri, Oct 24, 2025 at 05:09:02PM +0200, Jens Remus wrote: > Hello Peter, > > very nice! > > On 10/24/2025 4:51 PM, Peter Zijlstra wrote: > > > Subject: unwind_user/x86: Teach FP unwind about start of function > > From: Peter Zijlstra <[email protected]> > > Date: Fri Oct 24 12:31:10 CEST 2025 > > > > When userspace is interrupted at the start of a function, before we > > get a chance to complete the frame, unwind will miss one caller. > > > > X86 has a uprobe specific fixup for this, add bits to the generic > > unwinder to support this. > > > > Suggested-by: Jens Remus <[email protected]> > > Signed-off-by: Peter Zijlstra (Intel) <[email protected]> > > > +++ b/kernel/unwind/user.c > > > +static int unwind_user_next_fp(struct unwind_user_state *state) > > +{ > > + struct pt_regs *regs = task_pt_regs(current); > > + > > + const struct unwind_user_frame fp_frame = { > > + ARCH_INIT_USER_FP_FRAME(state->ws) > > + }; > > + const struct unwind_user_frame fp_entry_frame = { > > + ARCH_INIT_USER_FP_ENTRY_FRAME(state->ws) > > + }; > > + > > + if (state->topmost && unwind_user_at_function_start(regs)) > > + return unwind_user_next_common(state, &fp_entry_frame); > > IIUC this will cause kernel/unwind/user.c to fail compile on > architectures that will support HAVE_UNWIND_USER_SFRAME but not > HAVE_UNWIND_USER_FP (such as s390), and thus do not need to implement > unwind_user_at_function_start(). > > Either s390 would need to supply a dummy unwind_user_at_function_start() > or the unwind user sframe series needs to address this and supply > a dummy one if FP is not enabled, so that the code compiles with only > SFRAME enabled. > > What do you think?
I'll make it conditional on HAVE_UNWIND_USER_FP -- but tomorrow or so.
