On Thu, 7 Apr 2022 at 22:40, Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > > On Thu, Apr 7, 2022 at 5:44 AM Brendan Jackman <jackmanb@xxxxxxxxxx> wrote: > > > > On Thu, 7 Apr 2022 at 01:13, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > On Fri, Apr 1, 2022 at 6:59 PM Joanne Koong <joannekoong@xxxxxx> wrote: > > > > > > > > From: Joanne Koong <joannelkoong@xxxxxxxxx> > > > KP, Florent, Brendan, > > > > > > You always wanted a way to work with runtime-sized BPF ringbuf samples > > > without extra copies. This is the way we can finally do this with good > > > usability and simplicity. Please take a look and provide feedback. > > > Thanks! > > > > Thanks folks, this looks very cool. Please excuse my ignorance, one > > thing that isn't clear to me is does this work for user memory? Or > > would we need bpf_copy_from_user_dynptr to avoid an extra copy? > > Userspace programs will not be able to use or interact with dynptrs > directly. If there is data at a user-space address that needs to be > copied into the ringbuffer, the address can be passed to the bpf > program and then the bpf program can use a helper like > bpf_probe_read_user_dynptr (not added in this patchset but will be > part of a following one), which will read the contents at that user > address into the ringbuf dynptr. Ah yeah right, this is not for userspace programs just programs in the kernel that need to read user memory; the specific case I'm thinking of is reading the argv/env from the exec path. bpf_probe_read_user_dynptr sounds for sure like it would solve that case.
