From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, Martin KaFai Lau <kafai@fb.com>,
Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@chromium.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: [RFC/PATCH bpf-next 01/20] bpf: Add multi uprobe link
Date: Thu, 27 Apr 2023 15:14:29 +0200 [thread overview]
Message-ID: <ZEp1NUQpISWPZCN9@krava> (raw)
In-Reply-To: <CAEf4BzZ1C488vfg=Nvqv6wGhm7TEHdG9YEjaEBExYHCLML54cg@mail.gmail.com>
On Wed, Apr 26, 2023 at 12:00:10PM -0700, Andrii Nakryiko wrote:
> On Mon, Apr 24, 2023 at 9:05 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > Adding new multi uprobe link that allows to attach bpf program
> > to multiple uprobes.
> >
> > Uprobes to attach are specified via new link_create uprobe_multi
> > union:
> >
> > struct {
> > __u32 flags;
> > __u32 cnt;
> > __aligned_u64 paths;
> > __aligned_u64 offsets;
> > __aligned_u64 ref_ctr_offsets;
> > } uprobe_multi;
> >
> > Uprobes are defined in paths/offsets/ref_ctr_offsets arrays with
> > the same 'cnt' length. Each uprobe is defined with a single index
> > in all three arrays:
> >
> > paths[idx], offsets[idx] and/or ref_ctr_offsets[idx]
> >
> > The 'flags' supports single bit for now that marks the uprobe as
> > return probe.
> >
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > include/linux/trace_events.h | 6 +
> > include/uapi/linux/bpf.h | 14 +++
> > kernel/bpf/syscall.c | 16 ++-
> > kernel/trace/bpf_trace.c | 231 +++++++++++++++++++++++++++++++++++
> > 4 files changed, 265 insertions(+), 2 deletions(-)
> >
>
> [...]
>
> > @@ -4666,10 +4667,21 @@ static int link_create(union bpf_attr *attr, bpfptr_t uattr)
> > ret = bpf_perf_link_attach(attr, prog);
> > break;
> > case BPF_PROG_TYPE_KPROBE:
> > + /* Ensure that program with eBPF_TRACE_UPROBE_MULTI attach type can
>
> eBPF_TRACE_UPROBE_MULTI :)
will fix ;-)
>
> > + * attach only to uprobe_multi link. It has its own runtime context
> > + * which is specific for get_func_ip/get_attach_cookie helpers.
> > + */
> > + if (prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI &&
> > + attr->link_create.attach_type != BPF_TRACE_UPROBE_MULTI) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
>
> as Yonghong pointed out, you check this condition in
> bpf_uprobe_multi_link_attach() already, so why redundant check?
I tried to answer that in here:
https://lore.kernel.org/bpf/ZEjU0ykZZTHMVlZt@krava/
>
> > if (attr->link_create.attach_type == BPF_PERF_EVENT)
> > ret = bpf_perf_link_attach(attr, prog);
> > - else
> > + else if (attr->link_create.attach_type == BPF_TRACE_KPROBE_MULTI)
> > ret = bpf_kprobe_multi_link_attach(attr, prog);
> > + else if (attr->link_create.attach_type == BPF_TRACE_UPROBE_MULTI)
> > + ret = bpf_uprobe_multi_link_attach(attr, prog);
> > break;
> > default:
> > ret = -EINVAL;
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index bcf91bc7bf71..b84a7d01abf4 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -23,6 +23,7 @@
> > #include <linux/sort.h>
> > #include <linux/key.h>
> > #include <linux/verification.h>
> > +#include <linux/namei.h>
> >
> > #include <net/bpf_sk_storage.h>
> >
> > @@ -2901,3 +2902,233 @@ static u64 bpf_kprobe_multi_entry_ip(struct bpf_run_ctx *ctx)
> > return 0;
> > }
> > #endif
> > +
> > +#ifdef CONFIG_UPROBES
> > +struct bpf_uprobe_multi_link;
> > +
> > +struct bpf_uprobe {
> > + struct bpf_uprobe_multi_link *link;
> > + struct inode *inode;
> > + loff_t offset;
> > + loff_t ref_ctr_offset;
>
> you seem to need this only during link creation, so we are wasting 8
> bytes here per each instance of bpf_uprobe for no good reason? You
> should be able to easily move this out of bpf_uprobe into a temporary
> array.
right, we just need offset and inode, good catch, will fix
>
> > + struct uprobe_consumer consumer;
> > +};
> > +
> > +struct bpf_uprobe_multi_link {
> > + struct bpf_link link;
> > + u32 cnt;
> > + struct bpf_uprobe *uprobes;
> > +};
> > +
>
> [...]
>
> > + if (prog->expected_attach_type != BPF_TRACE_UPROBE_MULTI)
> > + return -EINVAL;
> > +
> > + flags = attr->link_create.uprobe_multi.flags;
> > + if (flags & ~BPF_F_UPROBE_MULTI_RETURN)
> > + return -EINVAL;
> > +
> > + upaths = u64_to_user_ptr(attr->link_create.uprobe_multi.paths);
> > + uoffsets = u64_to_user_ptr(attr->link_create.uprobe_multi.offsets);
> > + if (!!upaths != !!uoffsets)
> > + return -EINVAL;
>
> when having these as NULL would be ok? cnt == 0? or is there some
> valid situation?
ah nope, that needs to be always != NULL, will fix
>
> > +
> > + uref_ctr_offsets = u64_to_user_ptr(attr->link_create.uprobe_multi.ref_ctr_offsets);
>
> if upaths is NULL, uref_ctr_offsets should be NULL as well?
we need to fail when upaths is NULL, so that should be taken care of
thanks,
jirka
next prev parent reply other threads:[~2023-04-27 13:14 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 16:04 [RFC/PATCH bpf-next 00/20] bpf: Add multi uprobe link Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 01/20] " Jiri Olsa
2023-04-24 22:11 ` Alexei Starovoitov
2023-04-25 9:54 ` Jiri Olsa
2023-04-26 19:01 ` Andrii Nakryiko
2023-04-27 13:15 ` Jiri Olsa
2023-04-25 23:56 ` Yonghong Song
2023-04-26 7:37 ` Jiri Olsa
2023-04-26 19:00 ` Andrii Nakryiko
2023-04-27 13:14 ` Jiri Olsa [this message]
2023-04-26 19:17 ` Andrii Nakryiko
2023-04-27 13:15 ` Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 02/20] bpf: Add cookies support for uprobe_multi link Jiri Olsa
2023-04-26 0:03 ` Yonghong Song
2023-04-26 19:13 ` Andrii Nakryiko
2023-04-27 12:58 ` Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 03/20] bpf: Add bpf_get_func_ip helper support for uprobe link Jiri Olsa
2023-04-26 19:11 ` Andrii Nakryiko
2023-04-27 12:45 ` Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 04/20] libbpf: Update uapi bpf.h tools header Jiri Olsa
2023-04-26 19:14 ` Andrii Nakryiko
2023-04-27 12:58 ` Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 05/20] libbpf: Add uprobe_multi attach type and link names Jiri Olsa
2023-04-26 19:14 ` Andrii Nakryiko
2023-04-24 16:04 ` [RFC/PATCH bpf-next 06/20] libbpf: Factor elf_for_each_symbol function Jiri Olsa
2023-04-26 19:27 ` Andrii Nakryiko
2023-04-27 13:23 ` Jiri Olsa
2023-04-27 22:28 ` Andrii Nakryiko
2023-04-24 16:04 ` [RFC/PATCH bpf-next 07/20] libbpf: Add elf_find_multi_func_offset function Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 08/20] libbpf: Add elf_find_patern_func_offset function Jiri Olsa
2023-04-26 19:24 ` Andrii Nakryiko
2023-04-27 13:21 ` Jiri Olsa
2023-04-27 22:29 ` Andrii Nakryiko
2023-04-24 16:04 ` [RFC/PATCH bpf-next 09/20] libbpf: Add bpf_link_create support for multi uprobes Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 10/20] libbpf: Add bpf_program__attach_uprobe_multi_opts function Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 11/20] libbpf: Add support for uprobe.multi/uprobe.multi program sections Jiri Olsa
2023-04-26 19:31 ` Andrii Nakryiko
2023-04-24 16:04 ` [RFC/PATCH bpf-next 12/20] libbpf: Add uprobe multi link support to bpf_program__attach_usdt Jiri Olsa
2023-04-26 19:32 ` Andrii Nakryiko
2023-04-24 16:04 ` [RFC/PATCH bpf-next 13/20] selftests/bpf: Add uprobe_multi skel test Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 14/20] selftests/bpf: Add uprobe_multi api test Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 15/20] selftests/bpf: Add uprobe_multi link test Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 16/20] selftests/bpf: Add uprobe_multi test program Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 17/20] selftests/bpf: Add uprobe_multi bench test Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 18/20] selftests/bpf: Add usdt_multi test program Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 19/20] selftests/bpf: Add usdt_multi bench test Jiri Olsa
2023-04-24 16:04 ` [RFC/PATCH bpf-next 20/20] selftests/bpf: Add uprobe_multi cookie test Jiri Olsa
2023-04-26 19:09 ` [RFC/PATCH bpf-next 00/20] bpf: Add multi uprobe link Andrii Nakryiko
2023-04-27 12:44 ` Jiri Olsa
2023-04-27 22:24 ` Andrii Nakryiko
2023-04-28 10:55 ` Jiri Olsa
2023-04-28 21:19 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZEp1NUQpISWPZCN9@krava \
--to=olsajiri@gmail.com \
--cc=acme@kernel.org \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=sdf@google.com \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.