adding bpf@
On Tue, May 2, 2023 at 8:27 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Tue, 2 May 2023 12:53:53 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> > > while (entry->nr < entry->max_stack) {
> > > if (!valid_user_frame(fp, sizeof(frame)))
> > > break;
> >
> > This is broken, the sframe stuff is not NMI safe. First you need to
> > change perf to emit a forward reference to a 'next' user trace and then
> > emit the user trace on return-to-user.
> >
> > As is, perf does everything in-place from NMI context.
>
> Exactly. What I would like to see with the new sframe infrastructure is
> just a way to tell it "I want a user stack trace before going back to user
> space". Then all the work can be done in the ptrace path, where it's safe
> to memory map in the sframe section. It's not like the user space stack
> frame will change before going back to user space.
>
> This will allow for asking for the user space stack trace at any context,
> because the work will not be done until later. Of course, this may also
> require user space tooling to be updated to handle this case. Perf may
> already do that.
>
> It would also mean that even if you take multiple profiling hits in one
> system call, you will only get one user space stack trace. But that's a
> good thing. As the stack trace doesn't change, and you don't waste ring
> buffer space with unneeded duplicate stacks.
As discussed in the halls of LSF/MM2023, such lazily mapped .sframe in
approach won't work with BPF's bpf_get_stack() approach, which expects
stack trace to be grabbed and returned synchronously from NMI context.
But we can probably retrofit it into bpf_get_stackid()+STACK_TRACE BPF
map API.
Indu, please cc bpf@xxxxxxxxxxxxxxx for future revisions so we can
track and plan accordingly. Thank you!
>
> -- Steve
