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