[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fab1c1c1-a973-a32c-8936-d0d885d4b5af@huaweicloud.com>
Date: Fri, 6 Sep 2024 11:20:53 +0800
From: Hou Tao <houtao@...weicloud.com>
To: Tao Chen <chen.dylane@...il.com>
Cc: bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>, Eduard Zingerman <eddyz87@...il.com>,
Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...ichev.me>
Subject: Re: [RFC PATCH bpf-next] bpf: Check percpu map value size first
Hi,
On 9/6/2024 1:14 AM, Tao Chen wrote:
> Percpu map is often used, but the map value size limit often ignored,
> like issue: https://github.com/iovisor/bcc/issues/2519. Actually,
> percpu map value size is bound by PCPU_MIN_UNIT_SZIE, so we
s/SZIE/SIZE
> can check the value size whether it exceeds PCPU_MIN_UNIT_SZIE first,
The same typo here.
> like percpu map of local_storage. Maybe the error message seems clearer
> compared with "cannot allocate memory".
>
> the test case we create a percpu map with large value like:
> struct test_t {
> int a[100000];
> };
> struct {
> __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
> __uint(max_entries, 1);
> __type(key, u32);
> __type(value, struct test_t);
> } start SEC(".maps");
>
> test on ubuntu24.04 vm:
> libbpf: Error in bpf_create_map_xattr(start):Argument list too long(-7).
> Retrying without BTF.
Could you please convert it into a separated bpf selftest patch ?
>
> Signed-off-by: Tao Chen <chen.dylane@...il.com>
> ---
> kernel/bpf/arraymap.c | 3 +++
> kernel/bpf/hashtab.c | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index a43e62e2a8bb..7c3c32f156ff 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
> @@ -73,6 +73,9 @@ int array_map_alloc_check(union bpf_attr *attr)
> /* avoid overflow on round_up(map->value_size) */
> if (attr->value_size > INT_MAX)
> return -E2BIG;
> + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */
> + if (percpu && attr->value_size > PCPU_MIN_UNIT_SIZE)
> + return -E2BIG;
>
> return 0;
> }
Make sense. However because the map passes round_up(attr->value_size, 8)
to bpf_map_alloc_percpu(). Is it more reasonable to check
round_up(value_size) > PCPU_MIN_UNIT_SIZE instead ?
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 45c7195b65ba..16d590fe1ffb 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -462,6 +462,9 @@ static int htab_map_alloc_check(union bpf_attr *attr)
> * kmalloc-able later in htab_map_update_elem()
> */
> return -E2BIG;
> + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */
> + if (percpu && attr->value_size > PCPU_MIN_UNIT_SIZE)
> + return -E2BIG;
>
The percpu allocation logic is the same as the array map:
round_up(value_size, 8) is used.
> return 0;
> }
Powered by blists - more mailing lists