All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Hao Luo <haoluo@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>, KP Singh <kpsingh@kernel.org>,
	bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v1 3/9] bpf: Replace RET_XXX_OR_NULL with RET_XXX | PTR_MAYBE_NULL
Date: Mon, 6 Dec 2021 21:51:21 -0800	[thread overview]
Message-ID: <CAEf4BzZShouPUqbjr6fzqSy=Lp3Y36KTkFm6OaNSE=N0V9+_Xw@mail.gmail.com> (raw)
In-Reply-To: <20211206232227.3286237-4-haoluo@google.com>

On Mon, Dec 6, 2021 at 3:22 PM Hao Luo <haoluo@google.com> wrote:
>
> We have introduced a new type to make bpf_ret composable, by
> reserving high bits to represent flags.
>
> One of the flag is PTR_MAYBE_NULL, which indicates a pointer
> may be NULL. When applying this flag to ret_types, it means
> the returned value could be a NULL pointer. This patch
> switches the qualified arg_types to use this flag.
> The ret_types changed in this patch include:
>
> 1. RET_PTR_TO_MAP_VALUE_OR_NULL
> 2. RET_PTR_TO_SOCKET_OR_NULL
> 3. RET_PTR_TO_TCP_SOCK_OR_NULL
> 4. RET_PTR_TO_SOCK_COMMON_OR_NULL
> 5. RET_PTR_TO_ALLOC_MEM_OR_NULL
> 6. RET_PTR_TO_MEM_OR_BTF_ID_OR_NULL
> 7. RET_PTR_TO_BTF_ID_OR_NULL
>
> This patch doesn't eliminate the use of these names, instead
> it makes them aliases to 'RET_PTR_TO_XXX | PTR_MAYBE_NULL'.
>
> Signed-off-by: Hao Luo <haoluo@google.com>
> ---
>  include/linux/bpf.h   | 19 ++++++++++------
>  kernel/bpf/helpers.c  |  2 +-
>  kernel/bpf/verifier.c | 52 +++++++++++++++++++++----------------------
>  3 files changed, 39 insertions(+), 34 deletions(-)
>

[...]

> @@ -6570,28 +6570,28 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
>                                 return -EINVAL;
>                         }
>                         regs[BPF_REG_0].type =
> -                               fn->ret_type == RET_PTR_TO_MEM_OR_BTF_ID ?
> -                               PTR_TO_MEM : PTR_TO_MEM_OR_NULL;
> +                               (ret_type & PTR_MAYBE_NULL) ?
> +                               PTR_TO_MEM_OR_NULL : PTR_TO_MEM;

nit: I expected something like (let's use the fact that those flags
are the same across different enums):

regs[BPF_REG_0].type = PTR_TO_MEM | (ret_type & PTR_MAYBE_NULL);


>                         regs[BPF_REG_0].mem_size = tsize;
>                 } else {
>                         regs[BPF_REG_0].type =
> -                               fn->ret_type == RET_PTR_TO_MEM_OR_BTF_ID ?
> -                               PTR_TO_BTF_ID : PTR_TO_BTF_ID_OR_NULL;
> +                               (ret_type & PTR_MAYBE_NULL) ?
> +                               PTR_TO_BTF_ID_OR_NULL : PTR_TO_BTF_ID;

same as above

>                         regs[BPF_REG_0].btf = meta.ret_btf;
>                         regs[BPF_REG_0].btf_id = meta.ret_btf_id;
>                 }
> -       } else if (fn->ret_type == RET_PTR_TO_BTF_ID_OR_NULL ||
> -                  fn->ret_type == RET_PTR_TO_BTF_ID) {
> +       } else if (base_type(ret_type) == RET_PTR_TO_BTF_ID) {
>                 int ret_btf_id;
>
>                 mark_reg_known_zero(env, regs, BPF_REG_0);
> -               regs[BPF_REG_0].type = fn->ret_type == RET_PTR_TO_BTF_ID ?
> -                                                    PTR_TO_BTF_ID :
> -                                                    PTR_TO_BTF_ID_OR_NULL;
> +               regs[BPF_REG_0].type = (ret_type & PTR_MAYBE_NULL) ?
> +                                                    PTR_TO_BTF_ID_OR_NULL :
> +                                                    PTR_TO_BTF_ID;

and here


>                 ret_btf_id = *fn->ret_btf_id;
>                 if (ret_btf_id == 0) {
> -                       verbose(env, "invalid return type %d of func %s#%d\n",
> -                               fn->ret_type, func_id_name(func_id), func_id);
> +                       verbose(env, "invalid return type %lu of func %s#%d\n",
> +                               base_type(ret_type), func_id_name(func_id),

base type returns u32, shouldn't it be %u then?

> +                               func_id);
>                         return -EINVAL;
>                 }
>                 /* current BPF helper definitions are only coming from
> @@ -6600,8 +6600,8 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
>                 regs[BPF_REG_0].btf = btf_vmlinux;
>                 regs[BPF_REG_0].btf_id = ret_btf_id;
>         } else {
> -               verbose(env, "unknown return type %d of func %s#%d\n",
> -                       fn->ret_type, func_id_name(func_id), func_id);
> +               verbose(env, "unknown return type %lu of func %s#%d\n",
> +                       base_type(ret_type), func_id_name(func_id), func_id);

same %u

>                 return -EINVAL;
>         }
>
> --
> 2.34.1.400.ga245620fadb-goog
>

  reply	other threads:[~2021-12-07  5:51 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06 23:22 [PATCH bpf-next v1 0/9] Introduce composable bpf types Hao Luo
2021-12-06 23:22 ` [PATCH bpf-next v1 1/9] bpf: Introduce composable reg, ret and arg types Hao Luo
2021-12-06 23:22 ` [PATCH bpf-next v1 2/9] bpf: Replace ARG_XXX_OR_NULL with ARG_XXX | PTR_MAYBE_NULL Hao Luo
2021-12-07  5:45   ` Andrii Nakryiko
2021-12-07 18:52     ` Hao Luo
2021-12-06 23:22 ` [PATCH bpf-next v1 3/9] bpf: Replace RET_XXX_OR_NULL with RET_XXX " Hao Luo
2021-12-07  5:51   ` Andrii Nakryiko [this message]
2021-12-07 19:05     ` Hao Luo
2021-12-06 23:22 ` [PATCH bpf-next v1 4/9] bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX " Hao Luo
2021-12-07  6:08   ` Andrii Nakryiko
2021-12-08  3:37     ` Hao Luo
2021-12-08 20:03       ` Andrii Nakryiko
2021-12-09 21:45         ` Alexei Starovoitov
2021-12-10 19:56           ` Hao Luo
2021-12-13  1:51             ` Alexei Starovoitov
2021-12-13  2:02               ` Alexei Starovoitov
2021-12-17  0:32                 ` Hao Luo
2021-12-06 23:22 ` [PATCH bpf-next v1 5/9] bpf: Introduce MEM_RDONLY flag Hao Luo
2021-12-07  6:14   ` Andrii Nakryiko
2021-12-08  3:41     ` Hao Luo
2021-12-06 23:22 ` [PATCH bpf-next v1 6/9] bpf: Convert PTR_TO_MEM_OR_NULL to composable types Hao Luo
2021-12-06 23:22 ` [PATCH bpf-next v1 7/9] bpf: Make per_cpu_ptr return rdonly PTR_TO_MEM Hao Luo
2021-12-07  6:18   ` Andrii Nakryiko
2021-12-08  3:54     ` Hao Luo
2021-12-10 17:42       ` Andrii Nakryiko
2021-12-10 18:36         ` Hao Luo
2021-12-06 23:22 ` [PATCH bpf-next v1 8/9] bpf: Add MEM_RDONLY for helper args that are pointers to rdonly mem Hao Luo
2021-12-07  6:23   ` Andrii Nakryiko
2021-12-08  3:49     ` Hao Luo
2021-12-09 20:04       ` Hao Luo
2021-12-10 17:55         ` Andrii Nakryiko
2021-12-06 23:22 ` [PATCH bpf-next v1 9/9] bpf/selftests: Test PTR_TO_RDONLY_MEM Hao Luo

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='CAEf4BzZShouPUqbjr6fzqSy=Lp3Y36KTkFm6OaNSE=N0V9+_Xw@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=haoluo@google.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --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.