Re: [PATCH] bpf: fix excessively checking for elem_flags in batch update mode

[Daniel Borkmann]

On 7/17/24 1:15 PM, Lin Feng wrote:
> Currently generic_map_update_batch will reject all valid command flags for
> BPF_MAP_UPDATE_ELEM other than BPF_F_LOCK, which is overkill, map updating
> semantic does allow specify BPF_NOEXIST or BPF_EXIST even for batching
> update.
>
> Signed-off-by: Lin Feng <linf@xxxxxxxxxx>

[ +Hou/Brian ]

Please also add a BPF selftest along with this extension which exercises the
batch update and validates the behavior for the various flags which are now enabled.

Also, please discuss the semantics in the commit msg.. errors due to BPF_EXIST and
BPF_NOEXIST will cause bpf_map_update_value() to fail and then break the loop. It's
probably fine given batch.count (cp) will be propagated back to user space to tell
how many elements could actually get updated.

> ---
>   kernel/bpf/syscall.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 869265852d51..d85361f9a9b8 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -1852,7 +1852,7 @@ int generic_map_update_batch(struct bpf_map *map, struct file *map_file,
>   	void *key, *value;
>   	int err = 0;
>   
> -	if (attr->batch.elem_flags & ~BPF_F_LOCK)
> +	if ((attr->batch.elem_flags & ~BPF_F_LOCK) > BPF_EXIST)
>   		return -EINVAL;
>   
>   	if ((attr->batch.elem_flags & BPF_F_LOCK) &&