From: Kui-Feng Lee <sinquersw@gmail.com>
To: Eduard Zingerman <eddyz87@gmail.com>,
Kui-Feng Lee <thinker.li@gmail.com>,
bpf@vger.kernel.org, ast@kernel.org, martin.lau@linux.dev,
song@kernel.org, kernel-team@meta.com, andrii@kernel.org
Cc: kuifeng@meta.com
Subject: Re: [PATCH bpf-next 05/11] bpf: initialize/free array of btf_field(s).
Date: Thu, 11 Apr 2024 20:56:41 -0700 [thread overview]
Message-ID: <f1957694-13c3-4b4f-96f1-451b8acedc4b@gmail.com> (raw)
In-Reply-To: <57d016ec8ccb9cbc454f318d74b6d657de59ffcd.camel@gmail.com>
On 4/11/24 15:13, Eduard Zingerman wrote:
> On Tue, 2024-04-09 at 17:41 -0700, Kui-Feng Lee wrote:
> [...]
>
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index f397ccdc6d4b..ee53dcd14bd4 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -390,6 +390,9 @@ static inline u32 btf_field_type_align(enum btf_field_type type)
>>
>> static inline void bpf_obj_init_field(const struct btf_field *field, void *addr)
>> {
>> + u32 elem_size;
>> + int i;
>> +
>> memset(addr, 0, field->size);
>>
>> switch (field->type) {
>> @@ -400,6 +403,10 @@ static inline void bpf_obj_init_field(const struct btf_field *field, void *addr)
>> RB_CLEAR_NODE((struct rb_node *)addr);
>> break;
>> case BPF_LIST_HEAD:
>> + elem_size = field->size / field->nelems;
>> + for (i = 0; i < field->nelems; i++, addr += elem_size)
>> + INIT_LIST_HEAD((struct list_head *)addr);
>> + break;
>
> In btf_find_datasec_var() nelem > 1 is allowed for the following types:
> - BPF_LIST_{NODE,HEAD}
> - BPF_KPTR_{REF,UNREF,PERCPU}:
> - BPF_RB_{NODE,ROOT}
>
> Of these types bpf_obj_init_field() handles in a special way
> BPF_RB_NODE, BPF_LIST_HEAD and BPF_LIST_NODE.
> However, only BPF_LIST_HEAD handling is adjusted in this patch.
> Is there a reason to omit BPF_RB_NODE and BPF_LIST_NODE?
Declaring arrays of list nodes or rbtree nodes seems to be not useful
since they don't contain any useful information. Let me explain below.
We usually declare node fields in other struct types. I guess declaring
arrays of struct types containing node fields is what we actually want.
For example,
struct foo {
struct bpf_list_node node;
...
};
struct foo all_nodes[64];
However, the verifier doesn't look into fields of a outer struct type
except array fields handling by this patchset. In this case, a data
section, it doesn't look into foo even we declare a global variable of
struct foo. For example,
struct foo gFoo;
gFoo would not work since the verifier doesn't follow gFoo and look into
struct foo.
So, I decided not to support rbtree nodes and list nodes.
However, there are a discussion about looking into fields of struct
types in an outer struct type. So, we will have another patchset to
implement it. Once we have it, we can support the case of gFoo and
all_nodes described earlier.
>
>> case BPF_LIST_NODE:
>> INIT_LIST_HEAD((struct list_head *)addr);
>> break;
>
> [...]
>
next prev parent reply other threads:[~2024-04-12 3:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 0:41 [PATCH bpf-next 00/11] Enable BPF programs to declare arrays of kptr, bpf_rb_root, and bpf_list_head Kui-Feng Lee
2024-04-10 0:41 ` [PATCH bpf-next 01/11] bpf: Remove unnecessary checks on the offset of btf_field Kui-Feng Lee
2024-04-11 22:12 ` Eduard Zingerman
2024-04-10 0:41 ` [PATCH bpf-next 02/11] bpf: Remove unnecessary call to btf_field_type_size() Kui-Feng Lee
2024-04-11 22:12 ` Eduard Zingerman
2024-04-10 0:41 ` [PATCH bpf-next 03/11] bpf: Add nelems to struct btf_field_info and btf_field Kui-Feng Lee
2024-04-10 0:41 ` [PATCH bpf-next 04/11] bpf: check_map_kptr_access() compute the offset from the reg state Kui-Feng Lee
2024-04-11 22:13 ` Eduard Zingerman
2024-04-12 4:00 ` Kui-Feng Lee
2024-04-10 0:41 ` [PATCH bpf-next 05/11] bpf: initialize/free array of btf_field(s) Kui-Feng Lee
2024-04-11 22:13 ` Eduard Zingerman
2024-04-12 3:56 ` Kui-Feng Lee [this message]
2024-04-12 15:32 ` Eduard Zingerman
2024-04-12 17:00 ` Kui-Feng Lee
2024-04-10 0:41 ` [PATCH bpf-next 06/11] bpf: Find btf_field with the knowledge of arrays Kui-Feng Lee
2024-04-11 22:14 ` Eduard Zingerman
2024-04-12 2:00 ` Kui-Feng Lee
2024-04-10 0:41 ` [PATCH bpf-next 07/11] bpf: check_map_access() " Kui-Feng Lee
2024-04-11 22:14 ` Eduard Zingerman
2024-04-12 16:32 ` Kui-Feng Lee
2024-04-12 19:08 ` Eduard Zingerman
2024-04-12 19:29 ` Kui-Feng Lee
2024-04-12 19:50 ` Eduard Zingerman
2024-04-10 0:41 ` [PATCH bpf-next 08/11] bpf: Enable and verify btf_field arrays Kui-Feng Lee
2024-04-10 0:41 ` [PATCH bpf-next 09/11] selftests/bpf: Test global kptr arrays Kui-Feng Lee
2024-04-10 0:41 ` [PATCH bpf-next 10/11] selftests/bpf: Test global bpf_rb_root arrays Kui-Feng Lee
2024-04-10 0:41 ` [PATCH bpf-next 11/11] selftests/bpf: Test global bpf_list_head arrays Kui-Feng Lee
-- strict thread matches above, loose matches on Subject: below --
2024-04-11 3:39 [PATCH bpf-next 05/11] bpf: initialize/free array of btf_field(s) kernel test robot
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=f1957694-13c3-4b4f-96f1-451b8acedc4b@gmail.com \
--to=sinquersw@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=eddyz87@gmail.com \
--cc=kernel-team@meta.com \
--cc=kuifeng@meta.com \
--cc=martin.lau@linux.dev \
--cc=song@kernel.org \
--cc=thinker.li@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.