Re: [PATCH v4 28/39] unwind_user/deferred: Add deferred unwinding interface

On Thu, Jan 30, 2025 at 03:21:36PM -0500, Steven Rostedt wrote:
> Coming back from this. It would be fine if we could do the back trace when
> we come back from the scheduler, so it should not be an issue if the task
> even has to schedule again to fault in the sframe information.

So there would be two callback hook points:

  - schedule() after enabling preemption

  - task work

and first one wins?

> I was also wondering if the unwinder doesn't keep track of who requested
> the back trace, just that someone did. Then it would just take a single
> flag in the task struct to do the back trace. Return the "cookie" to the
> tracer that requested the back trace, and when you do the back trace, just
> call all callbacks with that cookie. Let the tracer decided if it wants to
> record the back trace or ignore it based on the cookie.
> 
> That is, the tracers would need to keep track of the cookies that it cares
> about, as if there's other tracers asking for stack traces on tasks that
> this tracer doesn't care about it needs to handle being called when it
> doesn't care about the stack trace. That said, if you want to trace all
> tasks, you can just ignore the cookies and record the traces.

Easy enough for the unwinder, but IIUC each tracer would have to
maintain a global list of pending cookies (and corresponding ptrs to
perf_event, trace_array, etc)?  Would that not create a lot of
contention?

Seems like there really needs to be some kind of per-task or per-request
state.

-- 
Josh