| Message ID | 20220709000439.243271-5-yosryahmed@google.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | bpf: rstat: cgroup hierarchical stats | expand |
On 7/8/22 5:04 PM, Yosry Ahmed wrote: > From: Hao Luo <haoluo@google.com> > > Cgroup_iter is a type of bpf_iter. It walks over cgroups in three modes: > > - walking a cgroup's descendants in pre-order. > - walking a cgroup's descendants in post-order. > - walking a cgroup's ancestors. > > When attaching cgroup_iter, one can set a cgroup to the iter_link > created from attaching. This cgroup is passed as a file descriptor and > serves as the starting point of the walk. If no cgroup is specified, > the starting point will be the root cgroup. > > 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. > > Signed-off-by: Hao Luo <haoluo@google.com> > Signed-off-by: Yosry Ahmed <yosryahmed@google.com> > Acked-by: Yonghong Song <yhs@fb.com> > --- > include/linux/bpf.h | 8 + > include/uapi/linux/bpf.h | 21 ++ > kernel/bpf/Makefile | 3 + > kernel/bpf/cgroup_iter.c | 242 ++++++++++++++++++ > tools/include/uapi/linux/bpf.h | 21 ++ > .../selftests/bpf/prog_tests/btf_dump.c | 4 +- > 6 files changed, 297 insertions(+), 2 deletions(-) > create mode 100644 kernel/bpf/cgroup_iter.c > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > index 2b21f2a3452ff..5de9de06e2551 100644 > --- a/include/linux/bpf.h > +++ b/include/linux/bpf.h > @@ -47,6 +47,7 @@ struct kobject; > struct mem_cgroup; > struct module; > struct bpf_func_state; > +struct cgroup; > > extern struct idr btf_idr; > extern spinlock_t btf_idr_lock; > @@ -1714,7 +1715,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; > + } 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 379e68fb866fc..6f5979e221927 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h > @@ -87,10 +87,27 @@ struct bpf_cgroup_storage_key { > __u32 attach_type; /* program attach type (enum bpf_attach_type) */ > }; > > +enum bpf_iter_cgroup_traversal_order { > + BPF_ITER_CGROUP_PRE = 0, /* pre-order traversal */ > + BPF_ITER_CGROUP_POST, /* post-order traversal */ > + BPF_ITER_CGROUP_PARENT_UP, /* traversal of ancestors up to the root */ > +}; > + > union bpf_iter_link_info { > struct { > __u32 map_fd; > } map; > + > + /* cgroup_iter walks either the live descendants of a cgroup subtree, or the ancestors > + * of a given cgroup. > + */ > + struct { > + /* Cgroup file descriptor. This is root of the subtree if for walking the > + * descendants; this is the starting cgroup if for walking the ancestors. Adding comment that cgroup_fd 0 means starting from root cgroup? Also, if I understand correctly, cgroup v1 is also supported here, right? If this is the case, for cgroup v1 which root cgroup will be used for cgroup_fd? It would be good to clarify here too. > + */ > + __u32 cgroup_fd; > + __u32 traversal_order; > + } cgroup; > }; > > /* BPF syscall commands, see bpf(2) man-page for more details. */ > @@ -6134,6 +6151,10 @@ struct bpf_link_info { > struct { > __u32 map_id; > } map; > + struct { > + __u32 traversal_order; > + __aligned_u64 cgroup_id; > + } cgroup; We actually has a problem here although I don't have a solution yet. Without this patch, for bpf_link_info structure, the output of pahole, struct { __u64 target_name __attribute__((__aligned__(8))); /* 0 8 */ __u32 target_name_len; /* 8 4 */ union { struct { __u32 map_id; /* 12 4 */ } map; /* 12 4 */ }; /* 12 4 */ union { struct { __u32 map_id; /* 0 4 */ } map; /* 0 4 */ }; } iter; You can see map_id has the offset 12 from the beginning of 'iter' structure. With this patch, struct { __u64 target_name __attribute__((__aligned__(8))); /* 0 8 */ __u32 target_name_len; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ union { struct { __u32 map_id; /* 16 4 */ } map; /* 16 4 */ struct { __u32 traversal_order; /* 16 4 */ /* XXX 4 bytes hole, try to pack */ __u64 cgroup_id; /* 24 8 */ } cgroup; /* 16 16 */ }; /* 16 16 */ union { struct { __u32 map_id; /* 0 4 */ } map; /* 0 4 */ struct { __u32 traversal_order; /* 0 4 */ /* XXX 4 bytes hole, try to pack */ __u64 cgroup_id; /* 8 8 */ } cgroup; /* 0 16 */ }; } iter; There is a 4 byte hole after member 'target_name_len'. So map_id will have a offset 16 from the start of structure 'iter'. This will break uapi. We probably won't be able to change the existing uapi with adding a ':32' after member 'target_name_len'. I don't have a good solution yet, but any suggestion is welcome. Also, for '__aligned_u64 cgroup_id', '__u64 cgroup_id' is enough. '__aligned_u64' mostly used for pointers. > }; > } iter; > struct { > diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile > index 057ba8e01e70f..00e05b69a4df1 100644 > --- a/kernel/bpf/Makefile > +++ b/kernel/bpf/Makefile > @@ -24,6 +24,9 @@ endif > ifeq ($(CONFIG_PERF_EVENTS),y) > obj-$(CONFIG_BPF_SYSCALL) += stackmap.o > endif > +ifeq ($(CONFIG_CGROUPS),y) > +obj-$(CONFIG_BPF_SYSCALL) += cgroup_iter.o > +endif > obj-$(CONFIG_CGROUP_BPF) += cgroup.o > ifeq ($(CONFIG_INET),y) > obj-$(CONFIG_BPF_SYSCALL) += reuseport_array.o > diff --git a/kernel/bpf/cgroup_iter.c b/kernel/bpf/cgroup_iter.c > new file mode 100644 > index 0000000000000..8f50b326016e6 > --- /dev/null > +++ b/kernel/bpf/cgroup_iter.c > @@ -0,0 +1,242 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* Copyright (c) 2022 Google */ > +#include <linux/bpf.h> > +#include <linux/btf_ids.h> > +#include <linux/cgroup.h> > +#include <linux/kernel.h> > +#include <linux/seq_file.h> > + > +#include "../cgroup/cgroup-internal.h" /* cgroup_mutex and cgroup_is_dead */ > + > +/* cgroup_iter provides three modes of traversal to the cgroup hierarchy. > + * > + * 1. Walk the descendants of a cgroup in pre-order. > + * 2. Walk the descendants of a cgroup in post-order. > + * 2. Walk the ancestors of a cgroup. > + * > + * For walking descendants, cgroup_iter can walk in either pre-order or > + * post-order. For walking ancestors, the iter walks up from a cgroup to > + * the root. > + * > + * The iter program can terminate the walk early by returning 1. Walk > + * continues if prog returns 0. > + * > + * The prog can check (seq->num == 0) to determine whether this is > + * the first element. The prog may also be passed a NULL cgroup, > + * which means the walk has completed and the prog has a chance to > + * do post-processing, such as outputing an epilogue. > + * > + * Note: the iter_prog is called with cgroup_mutex held. > + */ > + > +struct bpf_iter__cgroup { > + __bpf_md_ptr(struct bpf_iter_meta *, meta); > + __bpf_md_ptr(struct cgroup *, cgroup); > +}; > + > +struct cgroup_iter_priv { > + struct cgroup_subsys_state *start_css; > + bool terminate; > + int order; > +}; > + > +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) > +{ > + struct cgroup_iter_priv *p = seq->private; > + > + mutex_lock(&cgroup_mutex); > + > + /* support only one session */ > + if (*pos > 0) > + return NULL; This might be okay. But want to check what is the practical upper limit for cgroups in a system and whether we may miss some cgroups. If this happens, it will be a surprise to the user. > + > + ++*pos; > + p->terminate = false; > + if (p->order == BPF_ITER_CGROUP_PRE) > + return css_next_descendant_pre(NULL, p->start_css); > + else if (p->order == BPF_ITER_CGROUP_POST) > + return css_next_descendant_post(NULL, p->start_css); > + else /* BPF_ITER_CGROUP_PARENT_UP */ > + return p->start_css; > +} > + > +static int __cgroup_iter_seq_show(struct seq_file *seq, > + struct cgroup_subsys_state *css, int in_stop); > + > +static void cgroup_iter_seq_stop(struct seq_file *seq, void *v) > +{ > + /* pass NULL to the prog for post-processing */ > + if (!v) > + __cgroup_iter_seq_show(seq, NULL, true); > + mutex_unlock(&cgroup_mutex); > +} > + [...]
On 7/10/22 5:19 PM, Yonghong Song wrote: > > > On 7/8/22 5:04 PM, Yosry Ahmed wrote: >> From: Hao Luo <haoluo@google.com> >> >> Cgroup_iter is a type of bpf_iter. It walks over cgroups in three modes: >> >> - walking a cgroup's descendants in pre-order. >> - walking a cgroup's descendants in post-order. >> - walking a cgroup's ancestors. >> >> When attaching cgroup_iter, one can set a cgroup to the iter_link >> created from attaching. This cgroup is passed as a file descriptor and >> serves as the starting point of the walk. If no cgroup is specified, >> the starting point will be the root cgroup. >> >> 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. >> >> Signed-off-by: Hao Luo <haoluo@google.com> >> Signed-off-by: Yosry Ahmed <yosryahmed@google.com> >> Acked-by: Yonghong Song <yhs@fb.com> >> --- >> include/linux/bpf.h | 8 + >> include/uapi/linux/bpf.h | 21 ++ >> kernel/bpf/Makefile | 3 + >> kernel/bpf/cgroup_iter.c | 242 ++++++++++++++++++ >> tools/include/uapi/linux/bpf.h | 21 ++ >> .../selftests/bpf/prog_tests/btf_dump.c | 4 +- >> 6 files changed, 297 insertions(+), 2 deletions(-) >> create mode 100644 kernel/bpf/cgroup_iter.c >> >> diff --git a/include/linux/bpf.h b/include/linux/bpf.h >> index 2b21f2a3452ff..5de9de06e2551 100644 >> --- a/include/linux/bpf.h >> +++ b/include/linux/bpf.h >> @@ -47,6 +47,7 @@ struct kobject; >> struct mem_cgroup; >> struct module; >> struct bpf_func_state; >> +struct cgroup; >> extern struct idr btf_idr; >> extern spinlock_t btf_idr_lock; >> @@ -1714,7 +1715,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; >> + } 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 379e68fb866fc..6f5979e221927 100644 >> --- a/include/uapi/linux/bpf.h >> +++ b/include/uapi/linux/bpf.h >> @@ -87,10 +87,27 @@ struct bpf_cgroup_storage_key { >> __u32 attach_type; /* program attach type (enum >> bpf_attach_type) */ >> }; >> +enum bpf_iter_cgroup_traversal_order { >> + BPF_ITER_CGROUP_PRE = 0, /* pre-order traversal */ >> + BPF_ITER_CGROUP_POST, /* post-order traversal */ >> + BPF_ITER_CGROUP_PARENT_UP, /* traversal of ancestors up to the >> root */ >> +}; >> + >> union bpf_iter_link_info { >> struct { >> __u32 map_fd; >> } map; >> + >> + /* cgroup_iter walks either the live descendants of a cgroup >> subtree, or the ancestors >> + * of a given cgroup. >> + */ >> + struct { >> + /* Cgroup file descriptor. This is root of the subtree if for >> walking the >> + * descendants; this is the starting cgroup if for walking >> the ancestors. > > Adding comment that cgroup_fd 0 means starting from root cgroup? > Also, if I understand correctly, cgroup v1 is also supported here, > right? If this is the case, for cgroup v1 which root cgroup will be > used for cgroup_fd? It would be good to clarify here too. > >> + */ >> + __u32 cgroup_fd; >> + __u32 traversal_order; >> + } cgroup; >> }; >> /* BPF syscall commands, see bpf(2) man-page for more details. */ >> @@ -6134,6 +6151,10 @@ struct bpf_link_info { >> struct { >> __u32 map_id; >> } map; >> + struct { >> + __u32 traversal_order; >> + __aligned_u64 cgroup_id; >> + } cgroup; > > We actually has a problem here although I don't have a solution yet. > > Without this patch, for bpf_link_info structure, the output of pahole, > > struct { > > __u64 target_name > __attribute__((__aligned__(8))); /* 0 8 */ > __u32 target_name_len; /* > 8 4 */ > union { > > struct { > > __u32 map_id; /* > 12 4 */ > } map; /* > 12 4 */ > }; /* > 12 4 */ > union { > struct { > __u32 map_id; /* > 0 4 */ > } map; /* 0 4 */ > }; > > } iter; > > You can see map_id has the offset 12 from the beginning of 'iter' > structure. > > With this patch, > > struct { > __u64 target_name > __attribute__((__aligned__(8))); /* 0 8 */ > __u32 target_name_len; /* > 8 4 */ > > /* XXX 4 bytes hole, try to pack */ > > union { > struct { > __u32 map_id; /* > 16 4 */ > } map; /* > 16 4 */ > struct { > __u32 traversal_order; /* > 16 4 */ > > /* XXX 4 bytes hole, try to > pack */ > > __u64 cgroup_id; /* > 24 8 */ > } cgroup; /* > 16 16 */ > }; /* > 16 16 */ > union { > struct { > __u32 map_id; /* > 0 4 */ > } map; /* 0 4 */ > struct { > __u32 traversal_order; > /* 0 4 */ > > /* XXX 4 bytes hole, try to > pack */ > > __u64 cgroup_id; /* > 8 8 */ > } cgroup; /* 0 16 */ > }; > > } iter; > > There is a 4 byte hole after member 'target_name_len'. So map_id will > have a offset 16 from the start of structure 'iter'. > > > This will break uapi. We probably won't be able to change the existing > uapi with adding a ':32' after member 'target_name_len'. I don't have > a good solution yet, but any suggestion is welcome. > > Also, for '__aligned_u64 cgroup_id', '__u64 cgroup_id' is enough. > '__aligned_u64' mostly used for pointers. Briefly discussed with Alexei, the following structure iter definition should work. Later on, if we need to addition fields for other iter's, for a single __u32, the field can be added to either the first or the second union. If fields are more than __u32, they can be placed in the second union. struct { __aligned_u64 target_name; /* in/out: target_name buffer ptr */ __u32 target_name_len; /* in/out: target_name buffer len */ union { struct { __u32 map_id; } map; }; union { struct { __u64 cgroup_id; __u32 traversal_order; } cgroup; }; } iter; > > >> }; >> } iter; >> struct { >> diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile >> index 057ba8e01e70f..00e05b69a4df1 100644 >> --- a/kernel/bpf/Makefile >> +++ b/kernel/bpf/Makefile >> @@ -24,6 +24,9 @@ endif >> ifeq ($(CONFIG_PERF_EVENTS),y) >> obj-$(CONFIG_BPF_SYSCALL) += stackmap.o >> endif >> +ifeq ($(CONFIG_CGROUPS),y) >> +obj-$(CONFIG_BPF_SYSCALL) += cgroup_iter.o >> +endif >> obj-$(CONFIG_CGROUP_BPF) += cgroup.o >> ifeq ($(CONFIG_INET),y) >> obj-$(CONFIG_BPF_SYSCALL) += reuseport_array.o >> diff --git a/kernel/bpf/cgroup_iter.c b/kernel/bpf/cgroup_iter.c >> new file mode 100644 >> index 0000000000000..8f50b326016e6 >> --- /dev/null >> +++ b/kernel/bpf/cgroup_iter.c >> @@ -0,0 +1,242 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* Copyright (c) 2022 Google */ >> +#include <linux/bpf.h> >> +#include <linux/btf_ids.h> >> +#include <linux/cgroup.h> >> +#include <linux/kernel.h> >> +#include <linux/seq_file.h> >> + >> +#include "../cgroup/cgroup-internal.h" /* cgroup_mutex and >> cgroup_is_dead */ >> + >> +/* cgroup_iter provides three modes of traversal to the cgroup >> hierarchy. >> + * >> + * 1. Walk the descendants of a cgroup in pre-order. >> + * 2. Walk the descendants of a cgroup in post-order. >> + * 2. Walk the ancestors of a cgroup. >> + * >> + * For walking descendants, cgroup_iter can walk in either pre-order or >> + * post-order. For walking ancestors, the iter walks up from a cgroup to >> + * the root. >> + * >> + * The iter program can terminate the walk early by returning 1. Walk >> + * continues if prog returns 0. >> + * >> + * The prog can check (seq->num == 0) to determine whether this is >> + * the first element. The prog may also be passed a NULL cgroup, >> + * which means the walk has completed and the prog has a chance to >> + * do post-processing, such as outputing an epilogue. >> + * >> + * Note: the iter_prog is called with cgroup_mutex held. >> + */ >> + >> +struct bpf_iter__cgroup { >> + __bpf_md_ptr(struct bpf_iter_meta *, meta); >> + __bpf_md_ptr(struct cgroup *, cgroup); >> +}; >> + >> +struct cgroup_iter_priv { >> + struct cgroup_subsys_state *start_css; >> + bool terminate; >> + int order; >> +}; >> + >> +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) >> +{ >> + struct cgroup_iter_priv *p = seq->private; >> + >> + mutex_lock(&cgroup_mutex); >> + >> + /* support only one session */ >> + if (*pos > 0) >> + return NULL; > > This might be okay. But want to check what is > the practical upper limit for cgroups in a system > and whether we may miss some cgroups. If this > happens, it will be a surprise to the user. > >> + >> + ++*pos; >> + p->terminate = false; >> + if (p->order == BPF_ITER_CGROUP_PRE) >> + return css_next_descendant_pre(NULL, p->start_css); >> + else if (p->order == BPF_ITER_CGROUP_POST) >> + return css_next_descendant_post(NULL, p->start_css); >> + else /* BPF_ITER_CGROUP_PARENT_UP */ >> + return p->start_css; >> +} >> + >> +static int __cgroup_iter_seq_show(struct seq_file *seq, >> + struct cgroup_subsys_state *css, int in_stop); >> + >> +static void cgroup_iter_seq_stop(struct seq_file *seq, void *v) >> +{ >> + /* pass NULL to the prog for post-processing */ >> + if (!v) >> + __cgroup_iter_seq_show(seq, NULL, true); >> + mutex_unlock(&cgroup_mutex); >> +} >> + > [...]
On Mon, Jul 11, 2022 at 4:20 PM Yonghong Song <yhs@fb.com> wrote: > > On 7/10/22 5:19 PM, Yonghong Song wrote: > > > > [...] > >> + > >> union bpf_iter_link_info { > >> struct { > >> __u32 map_fd; > >> } map; > >> + > >> + /* cgroup_iter walks either the live descendants of a cgroup > >> subtree, or the ancestors > >> + * of a given cgroup. > >> + */ > >> + struct { > >> + /* Cgroup file descriptor. This is root of the subtree if for > >> walking the > >> + * descendants; this is the starting cgroup if for walking > >> the ancestors. > > > > Adding comment that cgroup_fd 0 means starting from root cgroup? Sure. > > Also, if I understand correctly, cgroup v1 is also supported here, > > right? If this is the case, for cgroup v1 which root cgroup will be > > used for cgroup_fd? It would be good to clarify here too. > > IMO, the case of cgroup_fd = 0 combined with cgroup v1 should return errors. It's an invalid case. If anyone wants to use cgroup_iter on cgroup v1 hierarchy, they could explicitly open the subsystems' root directory and pass the fd. With that said, Yosry and I will test and confirm the behavior in this situation and clarify in the comment. Thanks for pointing this out. > >> + */ > >> + __u32 cgroup_fd; > >> + __u32 traversal_order; > >> + } cgroup; > >> }; > >> /* BPF syscall commands, see bpf(2) man-page for more details. */ > >> @@ -6134,6 +6151,10 @@ struct bpf_link_info { > >> struct { > >> __u32 map_id; > >> } map; > >> + struct { > >> + __u32 traversal_order; > >> + __aligned_u64 cgroup_id; > >> + } cgroup; > > > > We actually has a problem here although I don't have a solution yet. > > [...] > > > > There is a 4 byte hole after member 'target_name_len'. So map_id will > > have a offset 16 from the start of structure 'iter'. > > > > > > This will break uapi. We probably won't be able to change the existing > > uapi with adding a ':32' after member 'target_name_len'. I don't have > > a good solution yet, but any suggestion is welcome. > > > > Also, for '__aligned_u64 cgroup_id', '__u64 cgroup_id' is enough. > > '__aligned_u64' mostly used for pointers. > > Briefly discussed with Alexei, the following structure iter definition > should work. Later on, if we need to addition fields for other iter's, > for a single __u32, the field can be added to either the first or the > second union. If fields are more than __u32, they can be placed > in the second union. > > struct { > __aligned_u64 target_name; /* in/out: > target_name buffer ptr */ > __u32 target_name_len; /* in/out: > target_name buffer len */ > union { > struct { > __u32 map_id; > } map; > }; > union { > struct { > __u64 cgroup_id; > __u32 traversal_order; > } cgroup; > }; > } iter; > Thanks Yonghong for seeking the solution here. The solution looks good. I'm going to put your heads-up as comments there. One thing I'd like to confirm, when we query bpf_link_info for cgroup iter, do we also need to zero those fields for map_elem? > > > > > > >> }; > >> } iter; > >> struct { [...] > >> + > >> +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) > >> +{ > >> + struct cgroup_iter_priv *p = seq->private; > >> + > >> + mutex_lock(&cgroup_mutex); > >> + > >> + /* support only one session */ > >> + if (*pos > 0) > >> + return NULL; > > > > This might be okay. But want to check what is > > the practical upper limit for cgroups in a system > > and whether we may miss some cgroups. If this > > happens, it will be a surprise to the user. > > Ok. What's the max number of items supported in a single session? > >> + > >> + ++*pos; > >> + p->terminate = false; > >> + if (p->order == BPF_ITER_CGROUP_PRE) > >> + return css_next_descendant_pre(NULL, p->start_css); > >> + else if (p->order == BPF_ITER_CGROUP_POST) > >> + return css_next_descendant_post(NULL, p->start_css); > >> + else /* BPF_ITER_CGROUP_PARENT_UP */ > >> + return p->start_css; > >> +} > >> + > >> +static int __cgroup_iter_seq_show(struct seq_file *seq, > >> + struct cgroup_subsys_state *css, int in_stop); > >> + > >> +static void cgroup_iter_seq_stop(struct seq_file *seq, void *v) > >> +{ > >> + /* pass NULL to the prog for post-processing */ > >> + if (!v) > >> + __cgroup_iter_seq_show(seq, NULL, true); > >> + mutex_unlock(&cgroup_mutex); > >> +} > >> + > > [...]
On 7/11/22 5:42 PM, Hao Luo wrote: > On Mon, Jul 11, 2022 at 4:20 PM Yonghong Song <yhs@fb.com> wrote: >> >> On 7/10/22 5:19 PM, Yonghong Song wrote: >>> >>> > [...] >>>> + >>>> union bpf_iter_link_info { >>>> struct { >>>> __u32 map_fd; >>>> } map; >>>> + >>>> + /* cgroup_iter walks either the live descendants of a cgroup >>>> subtree, or the ancestors >>>> + * of a given cgroup. >>>> + */ >>>> + struct { >>>> + /* Cgroup file descriptor. This is root of the subtree if for >>>> walking the >>>> + * descendants; this is the starting cgroup if for walking >>>> the ancestors. >>> >>> Adding comment that cgroup_fd 0 means starting from root cgroup? > > Sure. > >>> Also, if I understand correctly, cgroup v1 is also supported here, >>> right? If this is the case, for cgroup v1 which root cgroup will be >>> used for cgroup_fd? It would be good to clarify here too. >>> > > IMO, the case of cgroup_fd = 0 combined with cgroup v1 should return > errors. It's an invalid case. If anyone wants to use cgroup_iter on > cgroup v1 hierarchy, they could explicitly open the subsystems' root > directory and pass the fd. With that said, Yosry and I will test and > confirm the behavior in this situation and clarify in the comment. > Thanks for pointing this out. sounds good. > >>>> + */ >>>> + __u32 cgroup_fd; >>>> + __u32 traversal_order; >>>> + } cgroup; >>>> }; >>>> /* BPF syscall commands, see bpf(2) man-page for more details. */ >>>> @@ -6134,6 +6151,10 @@ struct bpf_link_info { >>>> struct { >>>> __u32 map_id; >>>> } map; >>>> + struct { >>>> + __u32 traversal_order; >>>> + __aligned_u64 cgroup_id; >>>> + } cgroup; >>> >>> We actually has a problem here although I don't have a solution yet. >>> > [...] >>> >>> There is a 4 byte hole after member 'target_name_len'. So map_id will >>> have a offset 16 from the start of structure 'iter'. >>> >>> >>> This will break uapi. We probably won't be able to change the existing >>> uapi with adding a ':32' after member 'target_name_len'. I don't have >>> a good solution yet, but any suggestion is welcome. >>> >>> Also, for '__aligned_u64 cgroup_id', '__u64 cgroup_id' is enough. >>> '__aligned_u64' mostly used for pointers. >> >> Briefly discussed with Alexei, the following structure iter definition >> should work. Later on, if we need to addition fields for other iter's, >> for a single __u32, the field can be added to either the first or the >> second union. If fields are more than __u32, they can be placed >> in the second union. >> >> struct { >> __aligned_u64 target_name; /* in/out: >> target_name buffer ptr */ >> __u32 target_name_len; /* in/out: >> target_name buffer len */ >> union { >> struct { >> __u32 map_id; >> } map; >> }; >> union { >> struct { >> __u64 cgroup_id; >> __u32 traversal_order; >> } cgroup; >> }; >> } iter; >> > > Thanks Yonghong for seeking the solution here. The solution looks > good. I'm going to put your heads-up as comments there. One thing I'd > like to confirm, when we query bpf_link_info for cgroup iter, do we > also need to zero those fields for map_elem? I think we don't need to do that. User space expected to check target_name/target_name_len/cgroup only. For cgroup_iter, the 'map' value should be ignored. > >> >>> >>> >>>> }; >>>> } iter; >>>> struct { > [...] >>>> + >>>> +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) >>>> +{ >>>> + struct cgroup_iter_priv *p = seq->private; >>>> + >>>> + mutex_lock(&cgroup_mutex); >>>> + >>>> + /* support only one session */ >>>> + if (*pos > 0) >>>> + return NULL; >>> >>> This might be okay. But want to check what is >>> the practical upper limit for cgroups in a system >>> and whether we may miss some cgroups. If this >>> happens, it will be a surprise to the user. >>> > > Ok. What's the max number of items supported in a single session? The max number of items (cgroups) in a single session is determined by kernel_buffer_size which equals to 8 * PAGE_SIZE. So it really depends on how much data bpf program intends to send to user space. If each bpf program run intends to send 64B to user space, e.g., for cpu, memory, cpu pressure, mem pressure, io pressure, read rate, write rate, read/write rate. Then each session can support 512 cgroups. > >>>> + >>>> + ++*pos; >>>> + p->terminate = false; >>>> + if (p->order == BPF_ITER_CGROUP_PRE) >>>> + return css_next_descendant_pre(NULL, p->start_css); >>>> + else if (p->order == BPF_ITER_CGROUP_POST) >>>> + return css_next_descendant_post(NULL, p->start_css); >>>> + else /* BPF_ITER_CGROUP_PARENT_UP */ >>>> + return p->start_css; >>>> +} >>>> + >>>> +static int __cgroup_iter_seq_show(struct seq_file *seq, >>>> + struct cgroup_subsys_state *css, int in_stop); >>>> + >>>> +static void cgroup_iter_seq_stop(struct seq_file *seq, void *v) >>>> +{ >>>> + /* pass NULL to the prog for post-processing */ >>>> + if (!v) >>>> + __cgroup_iter_seq_show(seq, NULL, true); >>>> + mutex_unlock(&cgroup_mutex); >>>> +} >>>> + >>> [...]
On Mon, Jul 11, 2022 at 8:45 PM Yonghong Song <yhs@fb.com> wrote: > > On 7/11/22 5:42 PM, Hao Luo wrote: [...] > >>>> + > >>>> +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) > >>>> +{ > >>>> + struct cgroup_iter_priv *p = seq->private; > >>>> + > >>>> + mutex_lock(&cgroup_mutex); > >>>> + > >>>> + /* support only one session */ > >>>> + if (*pos > 0) > >>>> + return NULL; > >>> > >>> This might be okay. But want to check what is > >>> the practical upper limit for cgroups in a system > >>> and whether we may miss some cgroups. If this > >>> happens, it will be a surprise to the user. > >>> > > > > Ok. What's the max number of items supported in a single session? > > The max number of items (cgroups) in a single session is determined > by kernel_buffer_size which equals to 8 * PAGE_SIZE. So it really > depends on how much data bpf program intends to send to user space. > If each bpf program run intends to send 64B to user space, e.g., for > cpu, memory, cpu pressure, mem pressure, io pressure, read rate, write > rate, read/write rate. Then each session can support 512 cgroups. > Hi Yonghong, Sorry about the late reply. It's possible that the number of cgroup can be large, 1000+, in our production environment. But that may not be common. Would it be good to leave handling large number of cgroups as follow up for this patch? If it turns out to be a problem, to alleviate it, we could: 1. tell users to write program to skip a certain uninteresting cgroups. 2. support requesting large kernel_buffer_size for bpf_iter, maybe as a new bpf_iter flag. Hao > > [...] > >>> [...]
On 7/20/22 5:40 PM, Hao Luo wrote: > On Mon, Jul 11, 2022 at 8:45 PM Yonghong Song <yhs@fb.com> wrote: >> >> On 7/11/22 5:42 PM, Hao Luo wrote: > [...] >>>>>> + >>>>>> +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) >>>>>> +{ >>>>>> + struct cgroup_iter_priv *p = seq->private; >>>>>> + >>>>>> + mutex_lock(&cgroup_mutex); >>>>>> + >>>>>> + /* support only one session */ >>>>>> + if (*pos > 0) >>>>>> + return NULL; >>>>> >>>>> This might be okay. But want to check what is >>>>> the practical upper limit for cgroups in a system >>>>> and whether we may miss some cgroups. If this >>>>> happens, it will be a surprise to the user. >>>>> >>> >>> Ok. What's the max number of items supported in a single session? >> >> The max number of items (cgroups) in a single session is determined >> by kernel_buffer_size which equals to 8 * PAGE_SIZE. So it really >> depends on how much data bpf program intends to send to user space. >> If each bpf program run intends to send 64B to user space, e.g., for >> cpu, memory, cpu pressure, mem pressure, io pressure, read rate, write >> rate, read/write rate. Then each session can support 512 cgroups. >> > > Hi Yonghong, > > Sorry about the late reply. It's possible that the number of cgroup > can be large, 1000+, in our production environment. But that may not > be common. Would it be good to leave handling large number of cgroups > as follow up for this patch? If it turns out to be a problem, to > alleviate it, we could: > > 1. tell users to write program to skip a certain uninteresting cgroups. > 2. support requesting large kernel_buffer_size for bpf_iter, maybe as > a new bpf_iter flag. Currently if we intend to support multiple read() for cgroup_iter, the following is a very inefficient approach: in seq_file private data structure, remember the last cgroup visited and for the second read() syscall, do the traversal again (but not calling bpf program) until the last cgroup and proceed from there. This is inefficient and probably works. But if the last cgroup is gone from the hierarchy, that the above approach won't work. One possibility is to rememobe the last two cgroups. If the last cgroup is gone, check the 'next' cgroup based on the one before the last cgroup. If both are gone, we return NULL. But in any case, if there are additional cgroups not visited, in the second read(), we should not return NULL which indicates done with all cgroups. We may return EOPNOTSUPP to indicate there are missing cgroups due to not supported. Once users see EOPNOTSUPP which indicates there are missing cgroups, they can do more filtering in bpf program to avoid large data volume to user space. To provide a way to truely visit *all* cgroups, we can either use bpf_iter link_create->flags to increase the buffer size as your suggested in the above so user can try to allocate more kernel buffer size. Or implement proper second read() traversal which I don't have a good idea how to do it efficiently. > > Hao > >>> > [...] >>>>> [...]
On Thu, Jul 21, 2022 at 9:15 AM Yonghong Song <yhs@fb.com> wrote: > > > > On 7/20/22 5:40 PM, Hao Luo wrote: > > On Mon, Jul 11, 2022 at 8:45 PM Yonghong Song <yhs@fb.com> wrote: > >> > >> On 7/11/22 5:42 PM, Hao Luo wrote: > > [...] > >>>>>> + > >>>>>> +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) > >>>>>> +{ > >>>>>> + struct cgroup_iter_priv *p = seq->private; > >>>>>> + > >>>>>> + mutex_lock(&cgroup_mutex); > >>>>>> + > >>>>>> + /* support only one session */ > >>>>>> + if (*pos > 0) > >>>>>> + return NULL; > >>>>> > >>>>> This might be okay. But want to check what is > >>>>> the practical upper limit for cgroups in a system > >>>>> and whether we may miss some cgroups. If this > >>>>> happens, it will be a surprise to the user. > >>>>> > >>> > >>> Ok. What's the max number of items supported in a single session? > >> > >> The max number of items (cgroups) in a single session is determined > >> by kernel_buffer_size which equals to 8 * PAGE_SIZE. So it really > >> depends on how much data bpf program intends to send to user space. > >> If each bpf program run intends to send 64B to user space, e.g., for > >> cpu, memory, cpu pressure, mem pressure, io pressure, read rate, write > >> rate, read/write rate. Then each session can support 512 cgroups. > >> > > > > Hi Yonghong, > > > > Sorry about the late reply. It's possible that the number of cgroup > > can be large, 1000+, in our production environment. But that may not > > be common. Would it be good to leave handling large number of cgroups > > as follow up for this patch? If it turns out to be a problem, to > > alleviate it, we could: > > > > 1. tell users to write program to skip a certain uninteresting cgroups. > > 2. support requesting large kernel_buffer_size for bpf_iter, maybe as > > a new bpf_iter flag. > > Currently if we intend to support multiple read() for cgroup_iter, > the following is a very inefficient approach: > > in seq_file private data structure, remember the last cgroup visited > and for the second read() syscall, do the traversal again (but not > calling bpf program) until the last cgroup and proceed from there. > This is inefficient and probably works. But if the last cgroup is > gone from the hierarchy, that the above approach won't work. One > possibility is to remember the last two cgroups. If the last cgroup > is gone, check the 'next' cgroup based on the one before the last > cgroup. If both are gone, we return NULL. > I suspect in reality, just remembering the last cgroup (or two cgroups) may not be sufficient. First, I don't want to hold cgroup_mutex across multiple sessions. I assume it's also not safe to release cgroup_mutex in the middle of walking cgroup hierarchy. Supporting multiple read() can be nasty for cgroup_iter. > But in any case, if there are additional cgroups not visited, > in the second read(), we should not return NULL which indicates > done with all cgroups. We may return EOPNOTSUPP to indicate there > are missing cgroups due to not supported. > > Once users see EOPNOTSUPP which indicates there are missing > cgroups, they can do more filtering in bpf program to avoid > large data volume to user space. > Makes sense. Yonghong, one question to confirm, if the first read() overflows, does the user still get partial data? I'll change the return code to EOPNOTSUPP in v4 of this patchset. > To provide a way to truely visit *all* cgroups, > we can either use bpf_iter link_create->flags > to increase the buffer size as your suggested in the above so > user can try to allocate more kernel buffer size. Or implement > proper second read() traversal which I don't have a good idea > how to do it efficiently. I will try the buffer size increase first. Looks more doable. Do you mind putting this support as a follow-up? > > > > Hao > > > >>> > > [...] > >>>>> [...]
On 7/21/22 10:21 AM, Hao Luo wrote: > On Thu, Jul 21, 2022 at 9:15 AM Yonghong Song <yhs@fb.com> wrote: >> >> >> >> On 7/20/22 5:40 PM, Hao Luo wrote: >>> On Mon, Jul 11, 2022 at 8:45 PM Yonghong Song <yhs@fb.com> wrote: >>>> >>>> On 7/11/22 5:42 PM, Hao Luo wrote: >>> [...] >>>>>>>> + >>>>>>>> +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) >>>>>>>> +{ >>>>>>>> + struct cgroup_iter_priv *p = seq->private; >>>>>>>> + >>>>>>>> + mutex_lock(&cgroup_mutex); >>>>>>>> + >>>>>>>> + /* support only one session */ >>>>>>>> + if (*pos > 0) >>>>>>>> + return NULL; >>>>>>> >>>>>>> This might be okay. But want to check what is >>>>>>> the practical upper limit for cgroups in a system >>>>>>> and whether we may miss some cgroups. If this >>>>>>> happens, it will be a surprise to the user. >>>>>>> >>>>> >>>>> Ok. What's the max number of items supported in a single session? >>>> >>>> The max number of items (cgroups) in a single session is determined >>>> by kernel_buffer_size which equals to 8 * PAGE_SIZE. So it really >>>> depends on how much data bpf program intends to send to user space. >>>> If each bpf program run intends to send 64B to user space, e.g., for >>>> cpu, memory, cpu pressure, mem pressure, io pressure, read rate, write >>>> rate, read/write rate. Then each session can support 512 cgroups. >>>> >>> >>> Hi Yonghong, >>> >>> Sorry about the late reply. It's possible that the number of cgroup >>> can be large, 1000+, in our production environment. But that may not >>> be common. Would it be good to leave handling large number of cgroups >>> as follow up for this patch? If it turns out to be a problem, to >>> alleviate it, we could: >>> >>> 1. tell users to write program to skip a certain uninteresting cgroups. >>> 2. support requesting large kernel_buffer_size for bpf_iter, maybe as >>> a new bpf_iter flag. >> >> Currently if we intend to support multiple read() for cgroup_iter, >> the following is a very inefficient approach: >> >> in seq_file private data structure, remember the last cgroup visited >> and for the second read() syscall, do the traversal again (but not >> calling bpf program) until the last cgroup and proceed from there. >> This is inefficient and probably works. But if the last cgroup is >> gone from the hierarchy, that the above approach won't work. One >> possibility is to remember the last two cgroups. If the last cgroup >> is gone, check the 'next' cgroup based on the one before the last >> cgroup. If both are gone, we return NULL. >> > > I suspect in reality, just remembering the last cgroup (or two > cgroups) may not be sufficient. First, I don't want to hold > cgroup_mutex across multiple sessions. I assume it's also not safe to > release cgroup_mutex in the middle of walking cgroup hierarchy. > Supporting multiple read() can be nasty for cgroup_iter. Right, holding cgroup_mutex across sessions is not bad idea and I didn't recommend it either. I am aware of remembering last (one or two) cgroups are not 100% reliable. All other iters have similar issues w.r.t. across multiple sessions. But the idea is to find a *reasonable* start for the second and later session. For example, for task related iter, the previous session last tid can be remember and the next session starts with next tid after last tid based on idr. Some old processes might be gone, but we got a reasonable approximation. But cgroup is different, holding the cgroup pointer with an additional reference across sessions is not good. but holding cgroup id requires to traverse the cgroup hierarchy again and this is not efficient. Maybe other people has a better idea how to do this. > >> But in any case, if there are additional cgroups not visited, >> in the second read(), we should not return NULL which indicates >> done with all cgroups. We may return EOPNOTSUPP to indicate there >> are missing cgroups due to not supported. >> >> Once users see EOPNOTSUPP which indicates there are missing >> cgroups, they can do more filtering in bpf program to avoid >> large data volume to user space. >> > > Makes sense. Yonghong, one question to confirm, if the first read() > overflows, does the user still get partial data? Yes, the first read() and subsequent read()'s will be okay until user space receives all 8KB data where 8KB is the kernel buffer size. For example, if user provides 1KB buffer size, the first 8 read() syscalls will return proper data to user space. After that, read() should return EOPNOTSUPP instead of return 0 where '0' indicates no more data. > > I'll change the return code to EOPNOTSUPP in v4 of this patchset. > >> To provide a way to truely visit *all* cgroups, >> we can either use bpf_iter link_create->flags >> to increase the buffer size as your suggested in the above so >> user can try to allocate more kernel buffer size. Or implement >> proper second read() traversal which I don't have a good idea >> how to do it efficiently. > > I will try the buffer size increase first. Looks more doable. Do you > mind putting this support as a follow-up? If we cannot finalize the solution to completely support arbitrary user output for cgroup_iter, we need to support EOPNOTSUPP so user knows it should adjust the bpf program to have less data to user space through seq_file. For example, they can put data into mmap-ed array map. Please explain such a limitation and how to workaround this in commit message clearly. So yes, to support buffer size increase through link_create flags or to support a better way to start iteration after 8KB user data can be a followup. > >>> >>> Hao >>> >>>>> >>> [...] >>>>>>> [...]
On Thu, Jul 21, 2022 at 11:16 AM Yonghong Song <yhs@fb.com> wrote: > > > > On 7/21/22 10:21 AM, Hao Luo wrote: > > On Thu, Jul 21, 2022 at 9:15 AM Yonghong Song <yhs@fb.com> wrote: > >> > >> > >> > >> On 7/20/22 5:40 PM, Hao Luo wrote: > >>> On Mon, Jul 11, 2022 at 8:45 PM Yonghong Song <yhs@fb.com> wrote: > >>>> > >>>> On 7/11/22 5:42 PM, Hao Luo wrote: > >>> [...] > >>>>>>>> + > >>>>>>>> +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) > >>>>>>>> +{ > >>>>>>>> + struct cgroup_iter_priv *p = seq->private; > >>>>>>>> + > >>>>>>>> + mutex_lock(&cgroup_mutex); > >>>>>>>> + > >>>>>>>> + /* support only one session */ > >>>>>>>> + if (*pos > 0) > >>>>>>>> + return NULL; > >>>>>>> > >>>>>>> This might be okay. But want to check what is > >>>>>>> the practical upper limit for cgroups in a system > >>>>>>> and whether we may miss some cgroups. If this > >>>>>>> happens, it will be a surprise to the user. > >>>>>>> > >>>>> > >>>>> Ok. What's the max number of items supported in a single session? > >>>> > >>>> The max number of items (cgroups) in a single session is determined > >>>> by kernel_buffer_size which equals to 8 * PAGE_SIZE. So it really > >>>> depends on how much data bpf program intends to send to user space. > >>>> If each bpf program run intends to send 64B to user space, e.g., for > >>>> cpu, memory, cpu pressure, mem pressure, io pressure, read rate, write > >>>> rate, read/write rate. Then each session can support 512 cgroups. > >>>> > >>> > >>> Hi Yonghong, > >>> > >>> Sorry about the late reply. It's possible that the number of cgroup > >>> can be large, 1000+, in our production environment. But that may not > >>> be common. Would it be good to leave handling large number of cgroups > >>> as follow up for this patch? If it turns out to be a problem, to > >>> alleviate it, we could: > >>> > >>> 1. tell users to write program to skip a certain uninteresting cgroups. > >>> 2. support requesting large kernel_buffer_size for bpf_iter, maybe as > >>> a new bpf_iter flag. > >> > >> Currently if we intend to support multiple read() for cgroup_iter, > >> the following is a very inefficient approach: > >> > >> in seq_file private data structure, remember the last cgroup visited > >> and for the second read() syscall, do the traversal again (but not > >> calling bpf program) until the last cgroup and proceed from there. > >> This is inefficient and probably works. But if the last cgroup is > >> gone from the hierarchy, that the above approach won't work. One > >> possibility is to remember the last two cgroups. If the last cgroup > >> is gone, check the 'next' cgroup based on the one before the last > >> cgroup. If both are gone, we return NULL. > >> > > > > I suspect in reality, just remembering the last cgroup (or two > > cgroups) may not be sufficient. First, I don't want to hold > > cgroup_mutex across multiple sessions. I assume it's also not safe to > > release cgroup_mutex in the middle of walking cgroup hierarchy. > > Supporting multiple read() can be nasty for cgroup_iter. > > Right, holding cgroup_mutex across sessions is not bad idea > and I didn't recommend it either. > > I am aware of remembering last (one or two) cgroups are not > 100% reliable. All other iters have similar issues w.r.t. > across multiple sessions. But the idea is to find a > *reasonable* start for the second and later session. > For example, for task related iter, the previous session > last tid can be remember and the next session starts > with next tid after last tid based on idr. Some old > processes might be gone, but we got a reasonable > approximation. But cgroup is different, holding > the cgroup pointer with an additional reference > across sessions is not good. but holding cgroup > id requires to traverse the cgroup hierarchy > again and this is not efficient. Maybe other people > has a better idea how to do this. > Makes sense. > > > >> But in any case, if there are additional cgroups not visited, > >> in the second read(), we should not return NULL which indicates > >> done with all cgroups. We may return EOPNOTSUPP to indicate there > >> are missing cgroups due to not supported. > >> > >> Once users see EOPNOTSUPP which indicates there are missing > >> cgroups, they can do more filtering in bpf program to avoid > >> large data volume to user space. > >> > > > > Makes sense. Yonghong, one question to confirm, if the first read() > > overflows, does the user still get partial data? > > Yes, the first read() and subsequent read()'s will be okay > until user space receives all 8KB data where 8KB is the > kernel buffer size. For example, if user provides 1KB buffer > size, the first 8 read() syscalls will return proper data > to user space. > > After that, read() should return > EOPNOTSUPP instead of return 0 where '0' indicates > no more data. > Sounds good. Will do that. > > > > > I'll change the return code to EOPNOTSUPP in v4 of this patchset. > > > >> To provide a way to truely visit *all* cgroups, > >> we can either use bpf_iter link_create->flags > >> to increase the buffer size as your suggested in the above so > >> user can try to allocate more kernel buffer size. Or implement > >> proper second read() traversal which I don't have a good idea > >> how to do it efficiently. > > > > I will try the buffer size increase first. Looks more doable. Do you > > mind putting this support as a follow-up? > > If we cannot finalize the solution to completely support > arbitrary user output for cgroup_iter, we need to support > EOPNOTSUPP so user knows it should adjust the bpf program > to have less data to user space through seq_file. For example, > they can put data into mmap-ed array map. Please explain > such a limitation and how to workaround this in commit > message clearly. > Acknowledged. I will put a comment in the code and also explain in the commit message. Thanks! > So yes, to support buffer size increase through link_create > flags or to support a better way to start iteration after 8KB > user data can be a followup. > > > > >>> > >>> Hao > >>> > >>>>> > >>> [...] > >>>>>>> [...]
diff --git a/include/linux/bpf.h b/include/linux/bpf.h index 2b21f2a3452ff..5de9de06e2551 100644 --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -47,6 +47,7 @@ struct kobject; struct mem_cgroup; struct module; struct bpf_func_state; +struct cgroup; extern struct idr btf_idr; extern spinlock_t btf_idr_lock; @@ -1714,7 +1715,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; + } 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 379e68fb866fc..6f5979e221927 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -87,10 +87,27 @@ struct bpf_cgroup_storage_key { __u32 attach_type; /* program attach type (enum bpf_attach_type) */ }; +enum bpf_iter_cgroup_traversal_order { + BPF_ITER_CGROUP_PRE = 0, /* pre-order traversal */ + BPF_ITER_CGROUP_POST, /* post-order traversal */ + BPF_ITER_CGROUP_PARENT_UP, /* traversal of ancestors up to the root */ +}; + union bpf_iter_link_info { struct { __u32 map_fd; } map; + + /* cgroup_iter walks either the live descendants of a cgroup subtree, or the ancestors + * of a given cgroup. + */ + struct { + /* Cgroup file descriptor. This is root of the subtree if for walking the + * descendants; this is the starting cgroup if for walking the ancestors. + */ + __u32 cgroup_fd; + __u32 traversal_order; + } cgroup; }; /* BPF syscall commands, see bpf(2) man-page for more details. */ @@ -6134,6 +6151,10 @@ struct bpf_link_info { struct { __u32 map_id; } map; + struct { + __u32 traversal_order; + __aligned_u64 cgroup_id; + } cgroup; }; } iter; struct { diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile index 057ba8e01e70f..00e05b69a4df1 100644 --- a/kernel/bpf/Makefile +++ b/kernel/bpf/Makefile @@ -24,6 +24,9 @@ endif ifeq ($(CONFIG_PERF_EVENTS),y) obj-$(CONFIG_BPF_SYSCALL) += stackmap.o endif +ifeq ($(CONFIG_CGROUPS),y) +obj-$(CONFIG_BPF_SYSCALL) += cgroup_iter.o +endif obj-$(CONFIG_CGROUP_BPF) += cgroup.o ifeq ($(CONFIG_INET),y) obj-$(CONFIG_BPF_SYSCALL) += reuseport_array.o diff --git a/kernel/bpf/cgroup_iter.c b/kernel/bpf/cgroup_iter.c new file mode 100644 index 0000000000000..8f50b326016e6 --- /dev/null +++ b/kernel/bpf/cgroup_iter.c @@ -0,0 +1,242 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* Copyright (c) 2022 Google */ +#include <linux/bpf.h> +#include <linux/btf_ids.h> +#include <linux/cgroup.h> +#include <linux/kernel.h> +#include <linux/seq_file.h> + +#include "../cgroup/cgroup-internal.h" /* cgroup_mutex and cgroup_is_dead */ + +/* cgroup_iter provides three modes of traversal to the cgroup hierarchy. + * + * 1. Walk the descendants of a cgroup in pre-order. + * 2. Walk the descendants of a cgroup in post-order. + * 2. Walk the ancestors of a cgroup. + * + * For walking descendants, cgroup_iter can walk in either pre-order or + * post-order. For walking ancestors, the iter walks up from a cgroup to + * the root. + * + * The iter program can terminate the walk early by returning 1. Walk + * continues if prog returns 0. + * + * The prog can check (seq->num == 0) to determine whether this is + * the first element. The prog may also be passed a NULL cgroup, + * which means the walk has completed and the prog has a chance to + * do post-processing, such as outputing an epilogue. + * + * Note: the iter_prog is called with cgroup_mutex held. + */ + +struct bpf_iter__cgroup { + __bpf_md_ptr(struct bpf_iter_meta *, meta); + __bpf_md_ptr(struct cgroup *, cgroup); +}; + +struct cgroup_iter_priv { + struct cgroup_subsys_state *start_css; + bool terminate; + int order; +}; + +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos) +{ + struct cgroup_iter_priv *p = seq->private; + + mutex_lock(&cgroup_mutex); + + /* support only one session */ + if (*pos > 0) + return NULL; + + ++*pos; + p->terminate = false; + if (p->order == BPF_ITER_CGROUP_PRE) + return css_next_descendant_pre(NULL, p->start_css); + else if (p->order == BPF_ITER_CGROUP_POST) + return css_next_descendant_post(NULL, p->start_css); + else /* BPF_ITER_CGROUP_PARENT_UP */ + return p->start_css; +} + +static int __cgroup_iter_seq_show(struct seq_file *seq, + struct cgroup_subsys_state *css, int in_stop); + +static void cgroup_iter_seq_stop(struct seq_file *seq, void *v) +{ + /* pass NULL to the prog for post-processing */ + if (!v) + __cgroup_iter_seq_show(seq, NULL, true); + mutex_unlock(&cgroup_mutex); +} + +static void *cgroup_iter_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct cgroup_subsys_state *curr = (struct cgroup_subsys_state *)v; + struct cgroup_iter_priv *p = seq->private; + + ++*pos; + if (p->terminate) + return NULL; + + if (p->order == BPF_ITER_CGROUP_PRE) + return css_next_descendant_pre(curr, p->start_css); + else if (p->order == BPF_ITER_CGROUP_POST) + return css_next_descendant_post(curr, p->start_css); + else /* BPF_ITER_CGROUP_PARENT_UP */ + return curr->parent; +} + +static int __cgroup_iter_seq_show(struct seq_file *seq, + struct cgroup_subsys_state *css, int in_stop) +{ + struct cgroup_iter_priv *p = seq->private; + struct bpf_iter__cgroup ctx; + struct bpf_iter_meta meta; + struct bpf_prog *prog; + int ret = 0; + + /* cgroup is dead, skip this element */ + if (css && cgroup_is_dead(css->cgroup)) + return 0; + + ctx.meta = &meta; + ctx.cgroup = css ? css->cgroup : NULL; + meta.seq = seq; + prog = bpf_iter_get_info(&meta, in_stop); + if (prog) + ret = bpf_iter_run_prog(prog, &ctx); + + /* if prog returns > 0, terminate after this element. */ + if (ret != 0) + p->terminate = true; + + return 0; +} + +static int cgroup_iter_seq_show(struct seq_file *seq, void *v) +{ + return __cgroup_iter_seq_show(seq, (struct cgroup_subsys_state *)v, + false); +} + +static const struct seq_operations cgroup_iter_seq_ops = { + .start = cgroup_iter_seq_start, + .next = cgroup_iter_seq_next, + .stop = cgroup_iter_seq_stop, + .show = cgroup_iter_seq_show, +}; + +BTF_ID_LIST_SINGLE(bpf_cgroup_btf_id, struct, cgroup) + +static int cgroup_iter_seq_init(void *priv, struct bpf_iter_aux_info *aux) +{ + struct cgroup_iter_priv *p = (struct cgroup_iter_priv *)priv; + struct cgroup *cgrp = aux->cgroup.start; + + p->start_css = &cgrp->self; + p->terminate = false; + p->order = aux->cgroup.order; + return 0; +} + +static const struct bpf_iter_seq_info cgroup_iter_seq_info = { + .seq_ops = &cgroup_iter_seq_ops, + .init_seq_private = cgroup_iter_seq_init, + .seq_priv_size = sizeof(struct cgroup_iter_priv), +}; + +static int bpf_iter_attach_cgroup(struct bpf_prog *prog, + union bpf_iter_link_info *linfo, + struct bpf_iter_aux_info *aux) +{ + int fd = linfo->cgroup.cgroup_fd; + int order = linfo->cgroup.traversal_order; + struct cgroup *cgrp; + + if (order != BPF_ITER_CGROUP_PRE && + order != BPF_ITER_CGROUP_POST && + order != BPF_ITER_CGROUP_PARENT_UP) + return -EINVAL; + + if (fd) + cgrp = cgroup_get_from_fd(fd); + else /* walk the entire hierarchy by default. */ + cgrp = cgroup_get_from_path("/"); + + if (IS_ERR(cgrp)) + return PTR_ERR(cgrp); + + aux->cgroup.start = cgrp; + aux->cgroup.order = order; + return 0; +} + +static void bpf_iter_detach_cgroup(struct bpf_iter_aux_info *aux) +{ + cgroup_put(aux->cgroup.start); +} + +static void bpf_iter_cgroup_show_fdinfo(const struct bpf_iter_aux_info *aux, + struct seq_file *seq) +{ + char *buf; + + buf = kzalloc(PATH_MAX, GFP_KERNEL); + if (!buf) { + seq_puts(seq, "cgroup_path:\t<unknown>\n"); + goto show_order; + } + + /* If cgroup_path_ns() fails, buf will be an empty string, cgroup_path + * will print nothing. + * + * Path is in the calling process's cgroup namespace. + */ + cgroup_path_ns(aux->cgroup.start, buf, PATH_MAX, + current->nsproxy->cgroup_ns); + seq_printf(seq, "cgroup_path:\t%s\n", buf); + kfree(buf); + +show_order: + if (aux->cgroup.order == BPF_ITER_CGROUP_PRE) + seq_puts(seq, "traversal_order: pre\n"); + else if (aux->cgroup.order == BPF_ITER_CGROUP_POST) + seq_puts(seq, "traversal_order: post\n"); + else /* BPF_ITER_CGROUP_PARENT_UP */ + seq_puts(seq, "traversal_order: parent_up\n"); +} + +static int bpf_iter_cgroup_fill_link_info(const struct bpf_iter_aux_info *aux, + struct bpf_link_info *info) +{ + info->iter.cgroup.traversal_order = aux->cgroup.order; + info->iter.cgroup.cgroup_id = cgroup_id(aux->cgroup.start); + return 0; +} + +DEFINE_BPF_ITER_FUNC(cgroup, struct bpf_iter_meta *meta, + struct cgroup *cgroup) + +static struct bpf_iter_reg bpf_cgroup_reg_info = { + .target = "cgroup", + .attach_target = bpf_iter_attach_cgroup, + .detach_target = bpf_iter_detach_cgroup, + .show_fdinfo = bpf_iter_cgroup_show_fdinfo, + .fill_link_info = bpf_iter_cgroup_fill_link_info, + .ctx_arg_info_size = 1, + .ctx_arg_info = { + { offsetof(struct bpf_iter__cgroup, cgroup), + PTR_TO_BTF_ID_OR_NULL }, + }, + .seq_info = &cgroup_iter_seq_info, +}; + +static int __init bpf_cgroup_iter_init(void) +{ + bpf_cgroup_reg_info.ctx_arg_info[0].btf_id = bpf_cgroup_btf_id[0]; + return bpf_iter_reg_target(&bpf_cgroup_reg_info); +} + +late_initcall(bpf_cgroup_iter_init); diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index 379e68fb866fc..6f5979e221927 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -87,10 +87,27 @@ struct bpf_cgroup_storage_key { __u32 attach_type; /* program attach type (enum bpf_attach_type) */ }; +enum bpf_iter_cgroup_traversal_order { + BPF_ITER_CGROUP_PRE = 0, /* pre-order traversal */ + BPF_ITER_CGROUP_POST, /* post-order traversal */ + BPF_ITER_CGROUP_PARENT_UP, /* traversal of ancestors up to the root */ +}; + union bpf_iter_link_info { struct { __u32 map_fd; } map; + + /* cgroup_iter walks either the live descendants of a cgroup subtree, or the ancestors + * of a given cgroup. + */ + struct { + /* Cgroup file descriptor. This is root of the subtree if for walking the + * descendants; this is the starting cgroup if for walking the ancestors. + */ + __u32 cgroup_fd; + __u32 traversal_order; + } cgroup; }; /* BPF syscall commands, see bpf(2) man-page for more details. */ @@ -6134,6 +6151,10 @@ struct bpf_link_info { struct { __u32 map_id; } map; + struct { + __u32 traversal_order; + __aligned_u64 cgroup_id; + } cgroup; }; } iter; struct { diff --git a/tools/testing/selftests/bpf/prog_tests/btf_dump.c b/tools/testing/selftests/bpf/prog_tests/btf_dump.c index 5fce7008d1ff3..604a40777cfa8 100644 --- a/tools/testing/selftests/bpf/prog_tests/btf_dump.c +++ b/tools/testing/selftests/bpf/prog_tests/btf_dump.c @@ -764,8 +764,8 @@ static void test_btf_dump_struct_data(struct btf *btf, struct btf_dump *d, /* union with nested struct */ TEST_BTF_DUMP_DATA(btf, d, "union", str, union bpf_iter_link_info, BTF_F_COMPACT, - "(union bpf_iter_link_info){.map = (struct){.map_fd = (__u32)1,},}", - { .map = { .map_fd = 1 }}); + "(union bpf_iter_link_info){.map = (struct){.map_fd = (__u32)1,},.cgroup = (struct){.cgroup_fd = (__u32)1,.traversal_order = (__u32)1,},}", + { .cgroup = { .cgroup_fd = 1, .traversal_order = 1, }}); /* struct skb with nested structs/unions; because type output is so * complex, we don't do a string comparison, just verify we return