All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Joanne Koong <joannekoong@fb.com>
Cc: bpf <bpf@vger.kernel.org>, Andrii Nakryiko <andrii@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Joanne Koong <joannelkoong@gmail.com>
Subject: Re: [PATCH bpf-next v1 2/7] bpf: Add MEM_RELEASE as a bpf_type_flag
Date: Wed, 6 Apr 2022 11:42:00 -0700	[thread overview]
Message-ID: <CAEf4Bza0WECzFJyK4-mkJhd=fppUjhsbQbnPT16bdt76SJfjwA@mail.gmail.com> (raw)
In-Reply-To: <20220402015826.3941317-3-joannekoong@fb.com>

On Fri, Apr 1, 2022 at 7:00 PM Joanne Koong <joannekoong@fb.com> wrote:
>
> From: Joanne Koong <joannelkoong@gmail.com>
>
> Currently, we hardcode in the verifier which functions are release
> functions. We have no way of differentiating which argument is the one
> to be released (we assume it will always be the first argument).
>
> This patch adds MEM_RELEASE as a bpf_type_flag. This allows us to
> determine which argument in the function needs to be released, and
> removes having to hardcode a list of release functions into the
> verifier.
>
> Please note that currently, we only support one release argument in a
> helper function. In the future, if/when we need to support several
> release arguments within the function, MEM_RELEASE is necessary
> since there needs to be a way of differentiating which arguments are the
> release ones.
>
> In the near future, MEM_RELEASE will be used by dynptr helper functions
> such as bpf_free.
>
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> ---
>  include/linux/bpf.h          |  4 +++-
>  include/linux/bpf_verifier.h |  3 +--
>  kernel/bpf/btf.c             |  3 ++-
>  kernel/bpf/ringbuf.c         |  4 ++--
>  kernel/bpf/verifier.c        | 42 ++++++++++++++++++------------------
>  net/core/filter.c            |  2 +-
>  6 files changed, 30 insertions(+), 28 deletions(-)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 6f2558da9d4a..cb9f42866cde 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -344,7 +344,9 @@ enum bpf_type_flag {
>
>         MEM_UNINIT              = BIT(5 + BPF_BASE_TYPE_BITS),
>
> -       __BPF_TYPE_LAST_FLAG    = MEM_UNINIT,
> +       MEM_RELEASE             = BIT(6 + BPF_BASE_TYPE_BITS),

"MEM_" part seems a bit too specific, it's not necessarily (just)
about memory, it's more generally about "releasing resources" in
general, right? ARG_RELEASE or OBJ_RELEASE maybe?

> +
> +       __BPF_TYPE_LAST_FLAG    = MEM_RELEASE,
>  };
>

[...]

> -/* Determine whether the function releases some resources allocated by another
> - * function call. The first reference type argument will be assumed to be
> - * released by release_reference().
> +/* Determine whether the type releases some resources allocated by a
> + * previous function call.
>   */
> -static bool is_release_function(enum bpf_func_id func_id)
> +static bool type_is_release_mem(u32 type)
>  {
> -       return func_id == BPF_FUNC_sk_release ||
> -              func_id == BPF_FUNC_ringbuf_submit ||
> -              func_id == BPF_FUNC_ringbuf_discard;
> +       return type & MEM_RELEASE;
>  }
>

same skepticism regarding the need for this helper function, just
makes grepping code slightly harder

>  static bool may_be_acquire_function(enum bpf_func_id func_id)

[...]

  parent reply	other threads:[~2022-04-06 20:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-02  1:58 [PATCH bpf-next v1 0/7] Dynamic pointers Joanne Koong
2022-04-02  1:58 ` [PATCH bpf-next v1 1/7] bpf: Add MEM_UNINIT as a bpf_type_flag Joanne Koong
2022-04-06 18:33   ` Andrii Nakryiko
2022-04-02  1:58 ` [PATCH bpf-next v1 2/7] bpf: Add MEM_RELEASE " Joanne Koong
2022-04-04  7:34   ` Kumar Kartikeya Dwivedi
2022-04-04 19:04     ` Joanne Koong
2022-04-06 18:42   ` Andrii Nakryiko [this message]
2022-04-02  1:58 ` [PATCH bpf-next v1 3/7] bpf: Add bpf_dynptr_from_mem, bpf_malloc, bpf_free Joanne Koong
2022-04-06 22:23   ` Andrii Nakryiko
2022-04-08 22:04     ` Joanne Koong
2022-04-08 22:46       ` Andrii Nakryiko
2022-04-08 23:37         ` Joanne Koong
2022-04-09  1:11           ` Alexei Starovoitov
2022-04-12  2:12             ` Andrii Nakryiko
2022-04-15  1:43               ` Joanne Koong
2022-04-12  2:05           ` Andrii Nakryiko
2022-04-02  1:58 ` [PATCH bpf-next v1 4/7] bpf: Add bpf_dynptr_read and bpf_dynptr_write Joanne Koong
2022-04-02 13:35   ` Toke Høiland-Jørgensen
2022-04-04 20:18     ` Joanne Koong
2022-04-06 22:32   ` Andrii Nakryiko
2022-04-08 23:07     ` Joanne Koong
2022-04-02  1:58 ` [PATCH bpf-next v1 5/7] bpf: Add dynptr data slices Joanne Koong
2022-04-02  1:58 ` [PATCH bpf-next v1 6/7] bpf: Dynptr support for ring buffers Joanne Koong
2022-04-02  6:40   ` kernel test robot
2022-04-06 22:50   ` Andrii Nakryiko
2022-04-02  1:58 ` [PATCH bpf-next v1 7/7] bpf: Dynptr tests Joanne Koong
2022-04-06 23:11   ` Andrii Nakryiko
2022-04-08 23:16     ` Joanne Koong
2022-04-06 23:13 ` [PATCH bpf-next v1 0/7] Dynamic pointers Andrii Nakryiko
2022-04-07 12:44   ` Brendan Jackman
2022-04-07 20:40     ` Joanne Koong
2022-04-08 10:21       ` Brendan Jackman

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='CAEf4Bza0WECzFJyK4-mkJhd=fppUjhsbQbnPT16bdt76SJfjwA@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=joannekoong@fb.com \
    --cc=joannelkoong@gmail.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.