Re: [POC 5/5] x86_64: invoke SFrame based stack tracer for user space

From: Steven Rostedt <rostedt@goodmis.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	Indu Bhagat <indu.bhagat@oracle.com>,
	linux-toolchains@vger.kernel.org, daandemeyer@meta.com,
	andrii@kernel.org, kris.van.hees@oracle.com,
	elena.zannoni@oracle.com, nick.alcock@oracle.com
Subject: Re: [POC 5/5] x86_64: invoke SFrame based stack tracer for user space
Date: Tue, 16 May 2023 13:38:50 -0400	[thread overview]
Message-ID: <20230516133850.4685e72c@gandalf.local.home> (raw)
In-Reply-To: <CAEf4BzY498TqDDBYFWoUHi9RG3fdhfDmJPo0Nm-793N7A_eTLQ@mail.gmail.com>

On Tue, 16 May 2023 10:25:52 -0700
Andrii Nakryiko <andrii.nakryiko@gmail.com> 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.

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@vger.kernel.org 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.

-- Steve