[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200403085529.GD2784502@krava>
Date: Fri, 3 Apr 2020 10:55:29 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Florent Revest <revest@...omium.org>
Cc: Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
bpf@...r.kernel.org, Yonghong Song <yhs@...com>,
Martin KaFai Lau <kafai@...com>,
David Miller <davem@...hat.com>,
John Fastabend <john.fastabend@...il.com>,
Jesper Dangaard Brouer <hawk@...nel.org>,
Wenbo Zhang <ethercflow@...il.com>,
KP Singh <kpsingh@...omium.org>,
Andrii Nakryiko <andriin@...com>, bgregg@...flix.com,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [RFC 0/3] bpf: Add d_path helper
On Thu, Apr 02, 2020 at 04:03:00PM +0200, Florent Revest wrote:
> On Wed, 2020-04-01 at 13:09 +0200, Jiri Olsa wrote:
> > hi,
> > adding d_path helper to return full path for 'path' object.
> >
> > I originally added and used 'file_path' helper, which did the same,
> > but used 'struct file' object. Then realized that file_path is just
> > a wrapper for d_path, so we'd cover more calling sites if we add
> > d_path helper and allowed resolving BTF object within another object,
> > so we could call d_path also with file pointer, like:
> >
> > bpf_d_path(&file->f_path, buf, size);
> >
> > This feature is mainly to be able to add dpath (filepath originally)
> > function to bpftrace, which seems to work nicely now, like:
> >
> > # bpftrace -e 'kretfunc:fget { printf("%s\n", dpath(args->ret-
> > >f_path)); }'
> >
> > I'm not completely sure this is all safe and bullet proof and there's
> > no other way to do this, hence RFC post.
> >
> > I'd be happy also with file_path function, but I thought it'd be
> > a shame not to try to add d_path with the verifier change.
> > I'm open to any suggestions ;-)
>
> First of all I want to mention that we are really interested in this
> feature so thanks a lot for bringing it up Jiri! I have experimented
> with similar BPF helpers in the past few months so I hope my input can
> be helpful! :)
>
> One of our use-cases is to gather information about execution events,
> including a bunch of paths (such as the executable command, the
> resolved executable file path and the current-working-directory) and
> then output them to Perf.
> Each of those paths can be up to PATH_MAX(one page) long so we would
> pre-allocate a data structure with a few identifiers (to later
> reassemble the event from userspace) and a page of data and then we
> would output it using bpf_perf_event_output. However, with three mostly
> empty pages per event, we would quickly fill up the ring buffer and
> loose many events.
> This might be a bit out-of-scope at this moment but one of the
> teachings we got from playing with such a helper is that we would also
> need a helper for outputting strings to Perf, pre-pended with a header
> buffer.
I think bpftrace uses fixed size as well at some point,
but very small one, which is still sufficent for tools usage,
but we can always send only data with the size of the path
thanks for info
jirka
Powered by blists - more mailing lists