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) && >> >
