On Mon, Nov 17, 2025 at 3:01 PM Josh Poimboeuf <[email protected]> wrote: > > On Fri, Nov 14, 2025 at 10:44:20PM -0800, Dylan Hatch wrote: > > Sorry for the slow reply on this, I'm going to try and get a v3 out > > sometime after next week. > > > > On Wed, Sep 17, 2025 at 4:41 PM Josh Poimboeuf <[email protected]> wrote: > > > > > > As far I can tell, the *only* error condition being checked is if it > > > (successfully) fell back to frame pointers. > > > > By checking/handling error conditions, do you mean just marking the > > state as unreliable in any case where the unwind isn't successful with > > SFrame? > > Right, any sframe error it encounters along the way (including missing > sframe) would be a reason to mark it as unreliable. > > > I'm thinking if I can make the unwind_next_frame_sframe() code > > path handle the end of the stack correctly on its own, I can more > > strictly mark the trace as unreliable if it encounters any error. > > > > > > > > What if there was some bad or missing sframe data? Or some unexpected > > > condition on the stack? > > > > > > Also, does the exception handling code have correct cfi/sframe metadata? > > > > > > In order for it to be "reliable", we need to know the unwind reached the > > > end of the stack (e.g., the task pt_regs frame, from entry-from-user). > > > > It looks like the frame-pointer based method of handling the end of > > the stack involves calling kunwind_next_frame_record_meta() to extract > > and check frame_record_meta::type for FRAME_META_TYPE_FINAL. I think > > this currently assumes (based on the definition of 'struct > > frame_record') that the next FP and PC are right next to each other, > > alongside the meta type. But the sframe format stores separate entries > > for the FP and RA offsets, which makes extracting the meta type from > > this information a little bit murky to me. > > > > Would it make sense to fall back to the frame pointer method for the > > final stack frame? Or I guess I could define a new sframe-friendly > > meta frame record format? > > For sframe v3, I believe Indu is planning to add support for marking the > outermost frame. That would be one definitive way to know that the > stack trace made it to the end.
How would this work? Is there a way of determining at compile time which functions would end up being the outermost frame? > > Or, if the entry-from-user pt_regs frame is always stored at a certain > offset compared to the end of the task stack page, that might be another > way. It looks like kunwind_next_frame_record_meta() uses this strategy already. It checks that 'fp == &task_pt_regs(tsk)->stackframe' to validate that it has in fact reached the end of the stack. It seems like we need alternate versions of kunwind_next_frame_record_meta() and kunwind_next_regs_pc() that use the CFA calculated from the sframe data (instead of the frame pointer). Does that sound right? Thanks, Dylan On Mon, Nov 17, 2025 at 3:01 PM Josh Poimboeuf <[email protected]> wrote: > > On Fri, Nov 14, 2025 at 10:44:20PM -0800, Dylan Hatch wrote: > > Sorry for the slow reply on this, I'm going to try and get a v3 out > > sometime after next week. > > > > On Wed, Sep 17, 2025 at 4:41 PM Josh Poimboeuf <[email protected]> wrote: > > > > > > As far I can tell, the *only* error condition being checked is if it > > > (successfully) fell back to frame pointers. > > > > By checking/handling error conditions, do you mean just marking the > > state as unreliable in any case where the unwind isn't successful with > > SFrame? > > Right, any sframe error it encounters along the way (including missing > sframe) would be a reason to mark it as unreliable. > > > I'm thinking if I can make the unwind_next_frame_sframe() code > > path handle the end of the stack correctly on its own, I can more > > strictly mark the trace as unreliable if it encounters any error. > > > > > > > > What if there was some bad or missing sframe data? Or some unexpected > > > condition on the stack? > > > > > > Also, does the exception handling code have correct cfi/sframe metadata? > > > > > > In order for it to be "reliable", we need to know the unwind reached the > > > end of the stack (e.g., the task pt_regs frame, from entry-from-user). > > > > It looks like the frame-pointer based method of handling the end of > > the stack involves calling kunwind_next_frame_record_meta() to extract > > and check frame_record_meta::type for FRAME_META_TYPE_FINAL. I think > > this currently assumes (based on the definition of 'struct > > frame_record') that the next FP and PC are right next to each other, > > alongside the meta type. But the sframe format stores separate entries > > for the FP and RA offsets, which makes extracting the meta type from > > this information a little bit murky to me. > > > > Would it make sense to fall back to the frame pointer method for the > > final stack frame? Or I guess I could define a new sframe-friendly > > meta frame record format? > > For sframe v3, I believe Indu is planning to add support for marking the > outermost frame. That would be one definitive way to know that the > stack trace made it to the end. > > Or, if the entry-from-user pt_regs frame is always stored at a certain > offset compared to the end of the task stack page, that might be another > way. > > -- > Josh
