From: David Vernet <void@manifault.com>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: bpf@vger.kernel.org, andrii@kernel.org, memxor@gmail.com,
ast@kernel.org, daniel@iogearbox.net, toke@redhat.com
Subject: Re: [PATCH bpf-next v3 1/6] bpf: Add MEM_UNINIT as a bpf_type_flag
Date: Fri, 6 May 2022 08:07:27 -0700 [thread overview]
Message-ID: <20220506150727.73dvaiyf5rerggj3@dev0025.ash9.facebook.com> (raw)
In-Reply-To: <20220428211059.4065379-2-joannelkoong@gmail.com>
Hi Joanne,
On Thu, Apr 28, 2022 at 02:10:54PM -0700, Joanne Koong wrote:
> @@ -5523,7 +5517,6 @@ static const struct bpf_reg_types kptr_types = { .types = { PTR_TO_MAP_VALUE } }
> static const struct bpf_reg_types *compatible_reg_types[__BPF_ARG_TYPE_MAX] = {
> [ARG_PTR_TO_MAP_KEY] = &map_key_value_types,
> [ARG_PTR_TO_MAP_VALUE] = &map_key_value_types,
> - [ARG_PTR_TO_UNINIT_MAP_VALUE] = &map_key_value_types,
> [ARG_CONST_SIZE] = &scalar_types,
> [ARG_CONST_SIZE_OR_ZERO] = &scalar_types,
> [ARG_CONST_ALLOC_SIZE_OR_ZERO] = &scalar_types,
> @@ -5537,7 +5530,6 @@ static const struct bpf_reg_types *compatible_reg_types[__BPF_ARG_TYPE_MAX] = {
> [ARG_PTR_TO_BTF_ID] = &btf_ptr_types,
> [ARG_PTR_TO_SPIN_LOCK] = &spin_lock_types,
> [ARG_PTR_TO_MEM] = &mem_types,
> - [ARG_PTR_TO_UNINIT_MEM] = &mem_types,
> [ARG_PTR_TO_ALLOC_MEM] = &alloc_mem_types,
> [ARG_PTR_TO_INT] = &int_ptr_types,
> [ARG_PTR_TO_LONG] = &int_ptr_types,
> @@ -5711,8 +5703,7 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
> return -EACCES;
> }
Could (or should) this go in a separate patch? Even with removing
ARG_PTR_TO_UNINIT_MAP_VALUE, it seems like this could stand on its own. Not
sure what the norm is for how granular to split patches for bpf, so even if
it could go in its own patch, feel free to disregard if you think splitting
this off is excessive / unnecessary.
> - } else if (base_type(arg_type) == ARG_PTR_TO_MAP_VALUE ||
> - base_type(arg_type) == ARG_PTR_TO_UNINIT_MAP_VALUE) {
> + } else if (base_type(arg_type) == ARG_PTR_TO_MAP_VALUE) {
> if (type_may_be_null(arg_type) && register_is_null(reg))
> return 0;
>
> @@ -5811,7 +5801,7 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
> verbose(env, "invalid map_ptr to access map->value\n");
> return -EACCES;
> }
> - meta->raw_mode = (arg_type == ARG_PTR_TO_UNINIT_MAP_VALUE);
> + meta->raw_mode = arg_type & MEM_UNINIT;
Given that we're stashing in a bool here, should this be:
meta->raw_mode = (arg_type & MEM_UNINIT) != 0;
> err = check_helper_mem_access(env, regno,
> meta->map_ptr->value_size, false,
> meta);
> @@ -5838,11 +5828,11 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
> return -EACCES;
> } else if (arg_type == ARG_PTR_TO_FUNC) {
> meta->subprogno = reg->subprogno;
> - } else if (arg_type_is_mem_ptr(arg_type)) {
> + } else if (base_type(arg_type) == ARG_PTR_TO_MEM) {
> /* The access to this pointer is only checked when we hit the
> * next is_mem_size argument below.
> */
> - meta->raw_mode = (arg_type == ARG_PTR_TO_UNINIT_MEM);
> + meta->raw_mode = arg_type & MEM_UNINIT;
Same here.
> } else if (arg_type_is_mem_size(arg_type)) {
> bool zero_size_allowed = (arg_type == ARG_CONST_SIZE_OR_ZERO);
>
> @@ -6189,9 +6179,9 @@ static bool check_raw_mode_ok(const struct bpf_func_proto *fn)
> static bool check_args_pair_invalid(enum bpf_arg_type arg_curr,
> enum bpf_arg_type arg_next)
> {
> - return (arg_type_is_mem_ptr(arg_curr) &&
> + return (base_type(arg_curr) == ARG_PTR_TO_MEM &&
> !arg_type_is_mem_size(arg_next)) ||
> - (!arg_type_is_mem_ptr(arg_curr) &&
> + (base_type(arg_curr) != ARG_PTR_TO_MEM &&
> arg_type_is_mem_size(arg_next));
> }
What do you think about this as a possibly more concise way to express that
the curr and next args differ?
return (base_type(arg_curr) == ARG_PTR_TO_MEM) !=
arg_type_is_mem_size(arg_next);
Looks great overall!
Thanks,
David
next prev parent reply other threads:[~2022-05-06 15:07 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-28 21:10 [PATCH bpf-next v3 0/6] Dynamic pointers Joanne Koong
2022-04-28 21:10 ` [PATCH bpf-next v3 1/6] bpf: Add MEM_UNINIT as a bpf_type_flag Joanne Koong
2022-05-06 15:07 ` David Vernet [this message]
[not found] ` <CAJnrk1Yc7G9BamfcNDGXvhMbHcrebROxN97GPPNENJ9_vGF5XA@mail.gmail.com>
2022-05-06 20:32 ` David Vernet
2022-05-06 22:46 ` Andrii Nakryiko
2022-05-07 1:48 ` David Vernet
2022-05-09 17:10 ` Joanne Koong
2022-05-06 22:41 ` Andrii Nakryiko
2022-04-28 21:10 ` [PATCH bpf-next v3 2/6] bpf: Add verifier support for dynptrs and implement malloc dynptrs Joanne Koong
2022-05-06 23:30 ` Andrii Nakryiko
2022-05-09 18:58 ` Joanne Koong
2022-05-09 19:26 ` Andrii Nakryiko
2022-04-28 21:10 ` [PATCH bpf-next v3 3/6] bpf: Dynptr support for ring buffers Joanne Koong
2022-05-06 23:41 ` Andrii Nakryiko
2022-05-09 19:44 ` Joanne Koong
2022-05-09 20:28 ` Andrii Nakryiko
2022-05-09 20:35 ` Joanne Koong
2022-05-09 20:58 ` Andrii Nakryiko
2022-04-28 21:10 ` [PATCH bpf-next v3 4/6] bpf: Add bpf_dynptr_read and bpf_dynptr_write Joanne Koong
2022-05-06 23:48 ` Andrii Nakryiko
2022-05-09 17:15 ` Joanne Koong
2022-04-28 21:10 ` [PATCH bpf-next v3 5/6] bpf: Add dynptr data slices Joanne Koong
2022-05-06 23:57 ` Andrii Nakryiko
2022-05-09 17:21 ` Joanne Koong
2022-05-09 18:29 ` Andrii Nakryiko
2022-04-28 21:10 ` [PATCH bpf-next v3 6/6] bpf: Dynptr tests Joanne Koong
2022-05-07 0:09 ` Andrii Nakryiko
2022-05-06 22:35 ` [PATCH bpf-next v3 0/6] Dynamic pointers Andrii Nakryiko
2022-05-09 17:26 ` Joanne Koong
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=20220506150727.73dvaiyf5rerggj3@dev0025.ash9.facebook.com \
--to=void@manifault.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=joannelkoong@gmail.com \
--cc=memxor@gmail.com \
--cc=toke@redhat.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