lkml.org 
[lkml]   [2020]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v3 bpf-next 1/3] bpf: Add bpf_perf_prog_read_branches() helper
    Date
    On Thu, Jan 23, 2020 at 06:02:58PM -0800, Daniel Xu wrote:
    > On Thu Jan 23, 2020 at 4:49 PM, John Fastabend wrote:
    > [...]
    > > > * function eBPF program intends to call
    > > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
    > > > index 19e793aa441a..24c51272a1f7 100644
    > > > --- a/kernel/trace/bpf_trace.c
    > > > +++ b/kernel/trace/bpf_trace.c
    > > > @@ -1028,6 +1028,35 @@ static const struct bpf_func_proto bpf_perf_prog_read_value_proto = {
    > > > .arg3_type = ARG_CONST_SIZE,
    > > > };
    > > >
    > > > +BPF_CALL_3(bpf_perf_prog_read_branches, struct bpf_perf_event_data_kern *, ctx,
    > > > + void *, buf, u32, size)
    > > > +{
    > > > + struct perf_branch_stack *br_stack = ctx->data->br_stack;
    > > > + u32 to_copy = 0, to_clear = size;
    > > > + int err = -EINVAL;
    > > > +
    > > > + if (unlikely(!br_stack))
    > > > + goto clear;
    > > > +
    > > > + to_copy = min_t(u32, br_stack->nr * sizeof(struct perf_branch_entry), size);
    > > > + to_clear -= to_copy;
    > > > +
    > > > + memcpy(buf, br_stack->entries, to_copy);
    > > > + err = to_copy;
    > > > +clear:
    > >
    > >
    > > There appears to be agreement to clear the extra buffer on error but
    > > what about
    > > in the non-error case? I expect one usage pattern is to submit a fairly
    > > large
    > > buffer, large enough to handle worse case nr, in this case we end up
    > > zero'ing
    > > memory even in the succesful case. Can we skip the clear in this case?
    > > Maybe
    > > its not too important either way but seems unnecessary.
    After some thoughts, I also think clearing for non-error case
    is not ideal. DanielXu, is it the common use case to always
    have a large enough buf size to capture the interested data?

    > >
    > >
    > > > + memset(buf + to_copy, 0, to_clear);
    > > > + return err;
    > > > +}
    > >
    >
    > Given Yonghong's suggestion of a flag argument, we need to allow users
    > to pass in a null ptr while getting buffer size. So I'll change the `buf`
    > argument to be ARG_PTR_TO_MEM_OR_NULL, which requires the buffer be
    > initialized. We can skip zero'ing out altogether.
    >
    > Although I think the end result is the same -- now the user has to zero it
    > out. Unfortunately ARG_PTR_TO_UNINITIALIZED_MEM_OR_NULL is not
    > implemented yet.
    A "flags" arg can be added but not used to keep our option open in the
    future. Not sure it has to be implemented now though.
    I would think whether there is an immediate usecase to learn
    br_stack->nr through an extra bpf helper call in every event.

    When there is a use case for learning br_stack->nr,
    there may have multiple ways to do it also,
    this "flags" arg, or another helper,
    or br_stack->nr may be read directly with the help of BTF.

    \
     
     \ /
      Last update: 2020-01-24 09:26    [W:2.668 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site