Yonghong Song wrote:
> Commit a5cbe05a6673 ("bpf: Implement bpf iterator for
> map elements") added bpf iterator support for
> map elements. The map element bpf iterator requires
> info to identify a particular map. In the above
> commit, the attr->link_create.target_fd is used
> to carry map_fd and an enum bpf_iter_link_info
> is added to uapi to specify the target_fd actually
> representing a map_fd:
>     enum bpf_iter_link_info {
>       BPF_ITER_LINK_UNSPEC = 0,
>       BPF_ITER_LINK_MAP_FD = 1,
> 
>       MAX_BPF_ITER_LINK_INFO,
>     };
> 
> This is an extensible approach as we can grow
> enumerator for pid, cgroup_id, etc. and we can
> unionize target_fd for pid, cgroup_id, etc.
> But in the future, there are chances that
> more complex customization may happen, e.g.,
> for tasks, it could be filtered based on
> both cgroup_id and user_id.
> 
> This patch changed the uapi to have fields
>       __aligned_u64   iter_info;
>       __u32           iter_info_len;
> for additional iter_info for link_create.
> The iter_info is defined as
>       union bpf_iter_link_info {
>               struct {
>                       __u32   map_fd;
>               } map;
>       };
> 
> So future extension for additional customization
> will be easier. The bpf_iter_link_info will be
> passed to target callback to validate and generic
> bpf_iter framework does not need to deal it any
> more.
> 
> Note that map_fd = 0 will be considered invalid
> and -EBADF will be returned to user space.
> 
> Signed-off-by: Yonghong Song <y...@fb.com>
> ---

LGTM. I had to do some git log research on latest bpf iter work though to
parse the commit message, but I needed to do that anyways.

Acked-by: John Fastabend <john.fastab...@gmail.com>

Reply via email to