On Tue, May 16, 2023 at 10:38 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Tue, 16 May 2023 10:25:52 -0700 > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > 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. > > Note that we will likely not be able to use sframe in NMI context, and if > that's a requirement, then BPF will need to continue using the method it is > currently using. Yes, unfortunately. We should give users a way to use sframes, but transition might be slow. > > The best way to access sframe reliable is in normal context. NMI is > special, and really should never had been used to access user space > addresses. That was just a simple solution but not a good one. There's a > lot of hacks just to allow a page fault in NMI context. > See https://lwn.net/Articles/484932/ > > > > > Indu, please cc bpf@xxxxxxxxxxxxxxx for future revisions so we can > > track and plan accordingly. Thank you! > > I'll likely be taking over the kernel side of sframes. I'll be happy to > Cc that work to the bpf mailing list. Thanks! > > -- Steve
