Message-ID: <CADBMgpzmzyQgs4K3XoYf5h=C7vv-FDfNb5wharucyeoxUKo4bg@mail.gmail.com>
Date: Tue, 18 Nov 2025 19:17:26 -0800
From: Dylan Hatch <dylanbhatch@...gle.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, Indu Bhagat <indu.bhagat@...cle.com>, 
	Peter Zijlstra <peterz@...radead.org>, Will Deacon <will@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Jiri Kosina <jikos@...nel.org>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Weinan Liu <wnliu@...gle.com>, 
	Mark Rutland <mark.rutland@....com>, Ian Rogers <irogers@...gle.com>, 
	linux-toolchains@...r.kernel.org, linux-kernel@...r.kernel.org, 
	live-patching@...r.kernel.org, joe.lawrence@...hat.com, 
	Puranjay Mohan <puranjay@...nel.org>, Song Liu <song@...nel.org>, 
	Prasanna Kumar T S M <ptsm@...ux.microsoft.com>
Subject: Re: [PATCH v2 6/6] unwind: arm64: Add reliable stacktrace with sframe unwinder.

On Mon, Nov 17, 2025 at 3:01 PM Josh Poimboeuf <jpoimboe@...nel.org> 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 <jpoimboe@...nel.org> 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 <jpoimboe@...nel.org> 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 <jpoimboe@...nel.org> 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

Powered by blists - more mailing lists