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

[Lin Feng]

Hi Daniel,

Thanks for your reply! Without basic knowledge of rules of thumb for patch in
bpf, I didn't expect a single line change need that many more considerations,
and will do some more work on it following your sugguestion!

Thanks,
linfeng

On 7/20/24 00:22, Daniel Borkmann wrote:
> 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) &&
>>
>