bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Yonghong Song <yhs@fb.com>
Cc: Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 bpf-next 06/14] bpf: add bpf_get_user_ctx() BPF helper to access user_ctx value
Date: Thu, 29 Jul 2021 21:49:38 -0700	[thread overview]
Message-ID: <CAEf4BzY2fVJN5CEdWDDNkWQ9En4N6Rynnnzj7hTnWG65BqdusQ@mail.gmail.com> (raw)
In-Reply-To: <ca7119de-3bb5-7a68-4005-4485ec151bb9@fb.com>

On Thu, Jul 29, 2021 at 11:17 AM Yonghong Song <yhs@fb.com> wrote:
>
>
>
> On 7/26/21 9:12 AM, Andrii Nakryiko wrote:
> > Add new BPF helper, bpf_get_user_ctx(), which can be used by BPF programs to
> > get access to the user_ctx value, specified during BPF program attachment (BPF
> > link creation) time.
> >
> > Currently all perf_event-backed BPF program types support bpf_get_user_ctx()
> > helper. Follow-up patches will add support for fentry/fexit programs as well.
> >
> > While at it, mark bpf_tracing_func_proto() as static to make it obvious that
> > it's only used from within the kernel/trace/bpf_trace.c.
> >
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> > ---
> >   include/linux/bpf.h            |  3 ---
> >   include/uapi/linux/bpf.h       | 16 ++++++++++++++++
> >   kernel/trace/bpf_trace.c       | 35 +++++++++++++++++++++++++++++++++-
> >   tools/include/uapi/linux/bpf.h | 16 ++++++++++++++++
> >   4 files changed, 66 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 74b35faf0b73..94ebedc1e13a 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -2110,9 +2110,6 @@ extern const struct bpf_func_proto bpf_btf_find_by_name_kind_proto;
> >   extern const struct bpf_func_proto bpf_sk_setsockopt_proto;
> >   extern const struct bpf_func_proto bpf_sk_getsockopt_proto;
> >
> > -const struct bpf_func_proto *bpf_tracing_func_proto(
> > -     enum bpf_func_id func_id, const struct bpf_prog *prog);
> > -
> >   const struct bpf_func_proto *tracing_prog_func_proto(
> >     enum bpf_func_id func_id, const struct bpf_prog *prog);
> >
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index bc1fd54a8f58..96afeced3467 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -4856,6 +4856,21 @@ union bpf_attr {
> >    *          Get address of the traced function (for tracing and kprobe programs).
> >    *  Return
> >    *          Address of the traced function.
> > + *
> > + * u64 bpf_get_user_ctx(void *ctx)
> > + *   Description
> > + *           Get user_ctx value provided (optionally) during the program
> > + *           attachment. It might be different for each individual
> > + *           attachment, even if BPF program itself is the same.
> > + *           Expects BPF program context *ctx* as a first argument.
> > + *
> > + *           Supported for the following program types:
> > + *                   - kprobe/uprobe;
> > + *                   - tracepoint;
> > + *                   - perf_event.
>
> I think it is possible in the future we may need to support more
> program types with user_ctx, not just u64 but more than 64bit value.
> Should we may make this helper extensible like
>      long bpf_get_user_ctx(void *ctx, void *user_ctx, u32 user_ctx_len)
>
> The return value will 0 to be good and a negative indicating an error.
> What do you think?

I explicitly wanted to keep this user_ctx/bpf_cookie to a small fixed
size. __u64 is perfect because it's small enough to not require
dynamic memory allocation, but big enough to store any kind of index
into an array *or* user-space pointer. So if user needs more storage
than 8 bytes, they will be able to have a bigger array where
user_ctx/bpf_cookie is just an integer index or some sort of key into
hashmap, whichever is more convenient.

So I'd like to keep it lean and simple. It is already powerful enough
to support any scenario, IMO.

>
> > + *   Return
> > + *           Value specified by user at BPF link creation/attachment time
> > + *           or 0, if it was not specified.
> >    */
> >   #define __BPF_FUNC_MAPPER(FN)               \
> >       FN(unspec),                     \
> > @@ -5032,6 +5047,7 @@ union bpf_attr {
> >       FN(timer_start),                \
> >       FN(timer_cancel),               \
> >       FN(get_func_ip),                \
> > +     FN(get_user_ctx),               \
> >       /* */
> >
> >   /* integer value in 'imm' field of BPF_CALL instruction selects which helper
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index c9cf6a0d0fb3..b14978b3f6fb 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -975,7 +975,34 @@ static const struct bpf_func_proto bpf_get_func_ip_proto_kprobe = {
> >       .arg1_type      = ARG_PTR_TO_CTX,
> >   };
> >
> > -const struct bpf_func_proto *
> > +BPF_CALL_1(bpf_get_user_ctx_trace, void *, ctx)
> > +{
> > +     struct bpf_trace_run_ctx *run_ctx;
> > +
> > +     run_ctx = container_of(current->bpf_ctx, struct bpf_trace_run_ctx, run_ctx);
> > +     return run_ctx->user_ctx;
> > +}
> > +
> > +static const struct bpf_func_proto bpf_get_user_ctx_proto_trace = {
> > +     .func           = bpf_get_user_ctx_trace,
> > +     .gpl_only       = false,
> > +     .ret_type       = RET_INTEGER,
> > +     .arg1_type      = ARG_PTR_TO_CTX,
> > +};
> > +
> [...]

  reply	other threads:[~2021-07-30  4:49 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 16:11 [PATCH v2 bpf-next 00/14] BPF perf link and user-provided context value Andrii Nakryiko
2021-07-26 16:11 ` [PATCH v2 bpf-next 01/14] bpf: refactor BPF_PROG_RUN into a function Andrii Nakryiko
2021-07-29 16:49   ` Yonghong Song
2021-07-30  4:05     ` Andrii Nakryiko
2021-07-26 16:11 ` [PATCH v2 bpf-next 02/14] bpf: refactor BPF_PROG_RUN_ARRAY family of macros into functions Andrii Nakryiko
2021-07-29 17:04   ` Yonghong Song
2021-07-26 16:12 ` [PATCH v2 bpf-next 03/14] bpf: refactor perf_event_set_bpf_prog() to use struct bpf_prog input Andrii Nakryiko
2021-07-27  8:48   ` Peter Zijlstra
2021-07-29 17:09   ` Yonghong Song
2021-07-26 16:12 ` [PATCH v2 bpf-next 04/14] bpf: implement minimal BPF perf link Andrii Nakryiko
2021-07-27  9:04   ` Peter Zijlstra
2021-07-30  4:23     ` Andrii Nakryiko
2021-07-27  9:12   ` Peter Zijlstra
2021-07-27 20:56     ` Andrii Nakryiko
2021-07-27 15:40   ` Jiri Olsa
2021-07-27 20:56     ` Andrii Nakryiko
2021-07-29 17:35   ` Yonghong Song
2021-07-30  4:16     ` Andrii Nakryiko
2021-07-30  5:42       ` Yonghong Song
2021-07-26 16:12 ` [PATCH v2 bpf-next 05/14] bpf: allow to specify user-provided context value for BPF perf links Andrii Nakryiko
2021-07-27  9:11   ` Peter Zijlstra
2021-07-27 21:09     ` Andrii Nakryiko
2021-07-28  8:58       ` Peter Zijlstra
2021-07-29 18:00   ` Yonghong Song
2021-07-30  4:31     ` Andrii Nakryiko
2021-07-30  5:49       ` Yonghong Song
2021-07-30 17:48         ` Andrii Nakryiko
2021-07-30 21:34           ` Yonghong Song
2021-07-30 22:06             ` Andrii Nakryiko
2021-07-30 22:28               ` Yonghong Song
2021-07-26 16:12 ` [PATCH v2 bpf-next 06/14] bpf: add bpf_get_user_ctx() BPF helper to access user_ctx value Andrii Nakryiko
2021-07-29 18:17   ` Yonghong Song
2021-07-30  4:49     ` Andrii Nakryiko [this message]
2021-07-30  5:53       ` Yonghong Song
2021-07-26 16:12 ` [PATCH v2 bpf-next 07/14] libbpf: re-build libbpf.so when libbpf.map changes Andrii Nakryiko
2021-07-26 16:12 ` [PATCH v2 bpf-next 08/14] libbpf: remove unused bpf_link's destroy operation, but add dealloc Andrii Nakryiko
2021-07-26 16:12 ` [PATCH v2 bpf-next 09/14] libbpf: use BPF perf link when supported by kernel Andrii Nakryiko
2021-07-26 16:12 ` [PATCH v2 bpf-next 10/14] libbpf: add user_ctx support to bpf_link_create() API Andrii Nakryiko
2021-07-26 16:12 ` [PATCH v2 bpf-next 11/14] libbpf: add user_ctx to perf_event, kprobe, uprobe, and tp attach APIs Andrii Nakryiko
2021-07-30  1:11   ` Rafael David Tinoco
2021-07-26 16:12 ` [PATCH v2 bpf-next 12/14] selftests/bpf: test low-level perf BPF link API Andrii Nakryiko
2021-07-26 16:12 ` [PATCH v2 bpf-next 13/14] selftests/bpf: extract uprobe-related helpers into trace_helpers.{c,h} Andrii Nakryiko
2021-07-26 16:12 ` [PATCH v2 bpf-next 14/14] selftests/bpf: add user_ctx selftests for high-level APIs 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=CAEf4BzY2fVJN5CEdWDDNkWQ9En4N6Rynnnzj7hTnWG65BqdusQ@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=peterz@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).