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? > + > + return unwind_user_next_common(state, &fp_frame); > +} Thanks and regards, Jens -- Jens Remus Linux on Z Development (D3303) +49-7031-16-1128 Office [email protected] IBM IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294 IBM Data Privacy Statement: https://www.ibm.com/privacy/
