On Mon, Aug 15, 2022 at 9:17 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Fri, Aug 12, 2022 at 1:28 PM Hao Luo <haoluo@xxxxxxxxxx> wrote:
> >
> > Cgroup_iter is a type of bpf_iter. It walks over cgroups in four modes:
> >
> > - walking a cgroup's descendants in pre-order.
> > - walking a cgroup's descendants in post-order.
> > - walking a cgroup's ancestors.
> > - process only the given cgroup.
> >
> > When attaching cgroup_iter, one can set a cgroup to the iter_link
> > created from attaching. This cgroup is passed as a file descriptor
> > or cgroup id and serves as the starting point of the walk. If no
> > cgroup is specified, the starting point will be the root cgroup v2.
> >
> > For walking descendants, one can specify the order: either pre-order or
> > post-order. For walking ancestors, the walk starts at the specified
> > cgroup and ends at the root.
> >
> > One can also terminate the walk early by returning 1 from the iter
> > program.
> >
> > Note that because walking cgroup hierarchy holds cgroup_mutex, the iter
> > program is called with cgroup_mutex held.
> >
> > Currently only one session is supported, which means, depending on the
> > volume of data bpf program intends to send to user space, the number
> > of cgroups that can be walked is limited. For example, given the current
> > buffer size is 8 * PAGE_SIZE, if the program sends 64B data for each
> > cgroup, assuming PAGE_SIZE is 4kb, the total number of cgroups that can
> > be walked is 512. This is a limitation of cgroup_iter. If the output
> > data is larger than the kernel buffer size, after all data in the
> > kernel buffer is consumed by user space, the subsequent read() syscall
> > will signal EOPNOTSUPP. In order to work around, the user may have to
> > update their program to reduce the volume of data sent to output. For
> > example, skip some uninteresting cgroups. In future, we may extend
> > bpf_iter flags to allow customizing buffer size.
> >
> > Acked-by: Yonghong Song <yhs@xxxxxx>
> > Acked-by: Tejun Heo <tj@xxxxxxxxxx>
> > Signed-off-by: Hao Luo <haoluo@xxxxxxxxxx>
> > ---
> > include/linux/bpf.h | 8 +
> > include/uapi/linux/bpf.h | 35 +++
> > kernel/bpf/Makefile | 3 +
> > kernel/bpf/cgroup_iter.c | 283 ++++++++++++++++++
> > tools/include/uapi/linux/bpf.h | 35 +++
> > .../selftests/bpf/prog_tests/btf_dump.c | 4 +-
> > 6 files changed, 366 insertions(+), 2 deletions(-)
> > create mode 100644 kernel/bpf/cgroup_iter.c
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index a627a02cf8ab..ecb8c61178a1 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -48,6 +48,7 @@ struct mem_cgroup;
> > struct module;
> > struct bpf_func_state;
> > struct ftrace_ops;
> > +struct cgroup;
> >
> > extern struct idr btf_idr;
> > extern spinlock_t btf_idr_lock;
> > @@ -1730,7 +1731,14 @@ int bpf_obj_get_user(const char __user *pathname, int flags);
> > int __init bpf_iter_ ## target(args) { return 0; }
> >
> > struct bpf_iter_aux_info {
> > + /* for map_elem iter */
> > struct bpf_map *map;
> > +
> > + /* for cgroup iter */
> > + struct {
> > + struct cgroup *start; /* starting cgroup */
> > + int order;
>
> why not using enum as a type here?
>
Sorry Andrii, I missed your reply.
No special reasons. Will use enum in the next version.
> > + } cgroup;
> > };
> >
> > typedef int (*bpf_iter_attach_target_t)(struct bpf_prog *prog,
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index 7d1e2794d83e..bc3c901b9f70 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -87,10 +87,34 @@ struct bpf_cgroup_storage_key {
> > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > };
> >
> > +enum bpf_iter_order {
> > + BPF_ITER_DESCENDANTS_PRE = 0, /* walk descendants in pre-order. */
> > + BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> > + BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> > + BPF_ITER_SELF_ONLY, /* process only a single object. */
> > +};
> > +
> > union bpf_iter_link_info {
> > struct {
> > __u32 map_fd;
> > } map;
> > + struct {
> > + /* Users must specify order using one of the following values:
> > + * - BPF_ITER_DESCENDANTS_PRE
> > + * - BPF_ITER_DESCENDANTS_POST
> > + * - BPF_ITER_ANCESTORS_UP
> > + * - BPF_ITER_SELF_ONLY
> > + */
> > + __u32 order;
>
> same, we just declared the UAPI enum above, why not specify that this
> is that enum here?
>
Will use enum.
> > +
> > + /* At most one of cgroup_fd and cgroup_id can be non-zero. If
> > + * both are zero, the walk starts from the default cgroup v2
> > + * root. For walking v1 hierarchy, one should always explicitly
> > + * specify cgroup_fd.
> > + */
> > + __u32 cgroup_fd;
> > + __u64 cgroup_id;
>
> for my own education, does root cgroup has cgroup_id == 0?
>
Yeah, unfortunately, the root cgroup has cgroup_id == 1. :(
> > + } cgroup;
> > };
> >
>
> [...]
