On Thu, 19 Jun 2025 09:54:17 +0200
Peter Zijlstra <pet...@infradead.org> wrote:
> On Wed, Jun 18, 2025 at 11:29:39AM -0400, Steven Rostedt wrote:
>
> > Note, a request from the gcc folks is to add a system call that gives the
> > user space application a backtrace from its current location. This can be
> > handy for debugging as it would be similar to how we use dump_stack().
>
> That makes very little sense to me; apps can typically unwind themselves
> just fine, no? In fact, they can use DWARFs and all that.
Not really. It can in gdb, but doing it from a running app means that
the app needs a full parser, and access to the elf file it's running.
>
> Also, how about we don't make thing complicated and not confuse comments
> with things like this? Focus on the deferred stuff (that's what these
> patches are about) -- and then return-to-user is the one and only place
> that makes sense.
The change log had:
Add a function that must be called inside a faultable context that will
retrieve a user space stack trace. The function unwind_deferred_trace()
can be called by a tracer when a task is about to enter user space, or has
just come back from user space and has interrupts enabled.
It doesn't mention the backtrace thing. It only makes a statement that
it needs to be done in a faultable context. I renamed the function to:
unwind_user_faultable()
And updated the change log to:
unwind_user/deferred: Add unwind_user_faultable()
Add a new API to retrieve a user space callstack called
unwind_user_faultable(). The difference between this user space stack
tracer from the current user space stack tracer is that this must be
called from faultable context as it may use routines to access user space
data that needs to be faulted in.
It can be safely called from entering or exiting a system call as the code
The explanation is that it must be called in faultable context. It
doesn't add any more policy that that (like it having to be deferred).
-- Steve
