On Fri, 25 Apr 2025 08:24:47 -0700
Namhyung Kim <namhy...@kernel.org> wrote:
> > +/*
> > + * Returns:
> > +* > 0 : if already queued.
> > + * 0 : if it performed the queuing
> > + * < 0 : if it did not get queued.
> > + */
> > +static int deferred_request(struct perf_event *event)
> > +{
> > + struct callback_head *work = &event->pending_unwind_work;
> > + int pending;
> > + int ret;
>
> I'm not sure if it works for per-CPU events. The event is shared so any
> task can request the deferred callchains. Does it handle if task A
> requests one and scheduled out before going to the user mode, and task B
> on the CPU also requests another after that? I'm afraid not..
I was afraid of that.
This is no different that what Josh did in his last set in v4. I'm guessing
the issue is running with "-a", correct?
Could we just not use deferred when running with "-a" for now? Or could we
possibly just make the deferred stacktrace its own event? Have it be
possible that perf just registers a signal instance with the deferred
unwinding logic, and then perf can handle where to write the information. I
don't know perf well enough to implement that.
Josh's code had it call the unwind_deferred_init() and just used its own
event to callback to and that was called on hundreds of events when I ran:
perf record -g <whatever>
Same if I added the "-a" option.
The above function return values came from Josh's code:
https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/tree/kernel/unwind/deferred.c?h=sframe#n173
I just moved it out of deferred.c and into perf itself, and removed the
cookie logic.
>
> > +
> > + if (!current->mm || !user_mode(task_pt_regs(current)))
> > + return -EINVAL;
>
> Does it mean it cannot use deferred callstack when it's in the kernel
> mode like during a syscall?
task_pt_regs(current) will return the regs from when the task entered the
kernel. So the answer is no, it will still trace if an interrupt happened
while a task is in a system call.
-- Steve
