[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <ceddf1642622347c5208e25b020429354c523327fc5fe9b031212a9d91d8bd26@mail.kernel.org>
Date: Tue, 25 Nov 2025 15:24:20 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: leon.hwang@...ux.dev,bpf@...r.kernel.org
Cc: ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,jolsa@...nel.org,yonghong.song@...ux.dev,song@...nel.org,eddyz87@...il.com,dxu@...uu.xyz,deso@...teo.net,martin.lau@...ux.dev,john.fastabend@...il.com,kpsingh@...nel.org,sdf@...ichev.me,haoluo@...gle.com,shuah@...nel.org,kerneljasonxing@...il.com,chen.dylane@...ux.dev,willemb@...gle.com,paul.chaignon@...il.com,a.s.protopopov@...il.com,memxor@...il.com,yatsenko@...a.com,tklauser@...tanz.ch,leon.hwang@...ux.dev,kernel-patches-bot@...com,linux-kernel@...r.kernel.org,linux-kselftest@...r.kernel.org,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,clm@...a.com,ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next v11 3/8] bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_array maps
> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index 1eeb31c5b..241f11d4d 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
[ ... ]
> @@ -398,18 +405,18 @@ int bpf_percpu_array_update(struct bpf_map *map, void *key, void *value,
> struct bpf_array *array = container_of(map, struct bpf_array, map);
> u32 index = *(u32 *)key;
> void __percpu *pptr;
> - int cpu, off = 0;
> + void *ptr, *val;
> u32 size;
> + int cpu;
>
> - if (unlikely(map_flags > BPF_EXIST))
> - /* unknown flags */
> + if (unlikely(map_flags & BPF_F_LOCK))
> return -EINVAL;
>
> if (unlikely(index >= array->map.max_entries))
> /* all elements were pre-allocated, cannot insert a new one */
> return -E2BIG;
>
> - if (unlikely(map_flags == BPF_NOEXIST))
> + if (unlikely(map_flags & BPF_NOEXIST))
> /* all elements already exist */
> return -EEXIST;
This isn't a bug, but the change from equality check to bit test might
allow confusing flag combinations. The old code rejected map_flags > 2,
which prevented BPF_NOEXIST | BPF_EXIST (flags=3) entirely. With the new
bit test, userspace can pass both flags and BPF_NOEXIST takes precedence.
Should bpf_map_check_op_flags() validate mutual exclusivity of BPF_NOEXIST
and BPF_EXIST, similar to how it validates BPF_F_CPU and BPF_F_ALL_CPUS at
include/linux/bpf.h:3858?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/19674301388
Powered by blists - more mailing lists