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 <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Hao Luo <[email protected]>
---
include/linux/bpf.h | 8 +
include/uapi/linux/bpf.h | 38 +++
kernel/bpf/Makefile | 3 +
kernel/bpf/cgroup_iter.c | 286 ++++++++++++++++++
tools/include/uapi/linux/bpf.h | 38 +++
.../selftests/bpf/prog_tests/btf_dump.c | 4 +-
6 files changed, 375 insertions(+), 2 deletions(-)
create mode 100644 kernel/bpf/cgroup_iter.c
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 20c26aed7896..09b5c2167424 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;
+ } 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 59a217ca2dfd..4d758b2e70d6 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
__u32 attach_type; /* program attach type (enum bpf_attach_type) */
};
+enum bpf_iter_order {
+ BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
+ BPF_ITER_SELF, /* process only a single object. */
+ BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
+ BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
+ BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
+};
+
union bpf_iter_link_info {
struct {
__u32 map_fd;
} map;
+ struct {
+ /* Valid values include:
+ * - BPF_ITER_ORDER_DEFAULT
+ * - BPF_ITER_SELF
+ * - BPF_ITER_DESCENDANTS_PRE
+ * - BPF_ITER_DESCENDANTS_POST
+ * - BPF_ITER_ANCESTORS_UP
+ * for cgroup_iter, DEFAULT is equivalent to DESCENDANTS_PRE.
+ */
+ __u32 order;
+
+ /* 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;
+ } cgroup;
};
/* BPF syscall commands, see bpf(2) man-page for more details. */
@@ -6134,11 +6161,22 @@ struct bpf_link_info {
struct {
__aligned_u64 target_name; /* in/out: target_name buffer ptr */
__u32 target_name_len; /* in/out: target_name buffer len */
+
+ /* If the iter specific field is 32 bits, it can be put
+ * in the first or second union. Otherwise it should be
+ * put in the second union.
+ */
union {
struct {
__u32 map_id;
} map;
};
+ union {
+ struct {
+ __u64 cgroup_id;
+ __u32 order;
+ } cgroup;
+ };
} iter;
struct {
__u32 netns_ino;
diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
index 057ba8e01e70..00e05b69a4df 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 000000000000..c469252d0536
--- /dev/null
+++ b/kernel/bpf/cgroup_iter.c
@@ -0,0 +1,286 @@
+// 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 four 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.
+ * 3. Walk the ancestors of a cgroup.
+ * 4. Show the given cgroup only.
+ *
+ * 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.
+ *
+ * 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.
+ */
+
+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 visited_all;
+ 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);
+
+ /* cgroup_iter doesn't support read across multiple sessions. */
+ if (*pos > 0) {
+ if (p->visited_all)
+ return NULL;
+
+ /* Haven't visited all, but because cgroup_mutex has dropped,
+ * return -EOPNOTSUPP to indicate incomplete iteration.
+ */
+ return ERR_PTR(-EOPNOTSUPP);
+ }
+
+ ++*pos;
+ p->terminate = false;
+ p->visited_all = false;
+ if (p->order == BPF_ITER_DESCENDANTS_PRE)
+ return css_next_descendant_pre(NULL, p->start_css);
+ else if (p->order == BPF_ITER_DESCENDANTS_POST)
+ return css_next_descendant_post(NULL, p->start_css);
+ else if (p->order == BPF_ITER_ANCESTORS_UP)
+ return p->start_css;
+ else /* BPF_ITER_SELF */
+ 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)
+{
+ struct cgroup_iter_priv *p = seq->private;
+
+ mutex_unlock(&cgroup_mutex);
+
+ /* pass NULL to the prog for post-processing */
+ if (!v) {
+ __cgroup_iter_seq_show(seq, NULL, true);
+ p->visited_all = true;
+ }
+}
+
+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_DESCENDANTS_PRE)
+ return css_next_descendant_pre(curr, p->start_css);
+ else if (p->order == BPF_ITER_DESCENDANTS_POST)
+ return css_next_descendant_post(curr, p->start_css);
+ else if (p->order == BPF_ITER_ANCESTORS_UP)
+ return curr->parent;
+ else /* BPF_ITER_SELF */
+ return NULL;
+}
+
+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->visited_all = 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;
+ u64 id = linfo->cgroup.cgroup_id;
+ int order = linfo->cgroup.order;
+ struct cgroup *cgrp;
+
+ if (order == BPF_ITER_ORDER_DEFAULT)
+ order = BPF_ITER_DESCENDANTS_PRE;
+
+ if (order != BPF_ITER_DESCENDANTS_PRE &&
+ order != BPF_ITER_DESCENDANTS_POST &&
+ order != BPF_ITER_ANCESTORS_UP &&
+ order != BPF_ITER_SELF)
+ return -EINVAL;
+
+ if (fd && id)
+ return -EINVAL;
+
+ if (fd)
+ cgrp = cgroup_get_from_fd(fd);
+ else if (id)
+ cgrp = cgroup_get_from_id(id);
+ 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_DESCENDANTS_PRE)
+ seq_puts(seq, "order: pre\n");
+ else if (aux->cgroup.order == BPF_ITER_DESCENDANTS_POST)
+ seq_puts(seq, "order: post\n");
+ else if (aux->cgroup.order == BPF_ITER_ANCESTORS_UP)
+ seq_puts(seq, "order: up\n");
+ else /* BPF_ITER_SELF */
+ seq_puts(seq, "order: self\n");
+}
+
+static int bpf_iter_cgroup_fill_link_info(const struct bpf_iter_aux_info *aux,
+ struct bpf_link_info *info)
+{
+ info->iter.cgroup.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 59a217ca2dfd..4d758b2e70d6 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
__u32 attach_type; /* program attach type (enum bpf_attach_type) */
};
+enum bpf_iter_order {
+ BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
+ BPF_ITER_SELF, /* process only a single object. */
+ BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
+ BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
+ BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
+};
+
union bpf_iter_link_info {
struct {
__u32 map_fd;
} map;
+ struct {
+ /* Valid values include:
+ * - BPF_ITER_ORDER_DEFAULT
+ * - BPF_ITER_SELF
+ * - BPF_ITER_DESCENDANTS_PRE
+ * - BPF_ITER_DESCENDANTS_POST
+ * - BPF_ITER_ANCESTORS_UP
+ * for cgroup_iter, DEFAULT is equivalent to DESCENDANTS_PRE.
+ */
+ __u32 order;
+
+ /* 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;
+ } cgroup;
};
/* BPF syscall commands, see bpf(2) man-page for more details. */
@@ -6134,11 +6161,22 @@ struct bpf_link_info {
struct {
__aligned_u64 target_name; /* in/out: target_name buffer ptr */
__u32 target_name_len; /* in/out: target_name buffer len */
+
+ /* If the iter specific field is 32 bits, it can be put
+ * in the first or second union. Otherwise it should be
+ * put in the second union.
+ */
union {
struct {
__u32 map_id;
} map;
};
+ union {
+ struct {
+ __u64 cgroup_id;
+ __u32 order;
+ } cgroup;
+ };
} iter;
struct {
__u32 netns_ino;
diff --git a/tools/testing/selftests/bpf/prog_tests/btf_dump.c b/tools/testing/selftests/bpf/prog_tests/btf_dump.c
index 5fce7008d1ff..84c1cfaa2b02 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){.order = (__u32)1,.cgroup_fd = (__u32)1,},}",
+ { .cgroup = { .order = 1, .cgroup_fd = 1, }});
/* struct skb with nested structs/unions; because type output is so
* complex, we don't do a string comparison, just verify we return
--
2.37.1.559.g78731f0fdb-goog
On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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 <[email protected]>
> Acked-by: Tejun Heo <[email protected]>
> Signed-off-by: Hao Luo <[email protected]>
> ---
> include/linux/bpf.h | 8 +
> include/uapi/linux/bpf.h | 38 +++
> kernel/bpf/Makefile | 3 +
> kernel/bpf/cgroup_iter.c | 286 ++++++++++++++++++
> tools/include/uapi/linux/bpf.h | 38 +++
> .../selftests/bpf/prog_tests/btf_dump.c | 4 +-
> 6 files changed, 375 insertions(+), 2 deletions(-)
> create mode 100644 kernel/bpf/cgroup_iter.c
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 20c26aed7896..09b5c2167424 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;
> + } 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 59a217ca2dfd..4d758b2e70d6 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> };
>
> +enum bpf_iter_order {
> + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
why is this default order necessary? It just adds confusion (I had to
look up source code to know what is default order). I might have
missed some discussion, so if there is some very good reason, then
please document this in commit message. But I'd rather not do some
magical default order instead. We can set 0 to mean invalid and error
out, or just do SELF as the very first value (and if user forgot to
specify more fancy mode, they hopefully will quickly discover this in
their testing).
> + BPF_ITER_SELF, /* process only a single object. */
> + BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
> + BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> + BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> +};
> +
This is a somewhat pedantic nit, so feel free to ignore completely,
but don't DESCENDANTS_{PRE,POST} and ANCESTORS_UP also include "self"?
As it is right now, BPF_ITER_SELF name might be read as implying that
DESCENDANTS and ANCESTORS order don't include self. So I don't know,
maybe BPF_ITER_SELF_ONLY would be a bit clearer?
> union bpf_iter_link_info {
> struct {
> __u32 map_fd;
> } map;
> + struct {
> + /* Valid values include:
> + * - BPF_ITER_ORDER_DEFAULT
> + * - BPF_ITER_SELF
> + * - BPF_ITER_DESCENDANTS_PRE
> + * - BPF_ITER_DESCENDANTS_POST
> + * - BPF_ITER_ANCESTORS_UP
> + * for cgroup_iter, DEFAULT is equivalent to DESCENDANTS_PRE.
> + */
> + __u32 order;
> +
> + /* 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;
> + } cgroup;
> };
>
> /* BPF syscall commands, see bpf(2) man-page for more details. */
> @@ -6134,11 +6161,22 @@ struct bpf_link_info {
> struct {
> __aligned_u64 target_name; /* in/out: target_name buffer ptr */
> __u32 target_name_len; /* in/out: target_name buffer len */
> +
> + /* If the iter specific field is 32 bits, it can be put
> + * in the first or second union. Otherwise it should be
> + * put in the second union.
> + */
> union {
> struct {
> __u32 map_id;
> } map;
> };
> + union {
> + struct {
> + __u64 cgroup_id;
> + __u32 order;
> + } cgroup;
> + };
> } iter;
But other than above, I like how UAPI looks like, thanks!
[...]
> + *
> + * 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.
typo: outputting
> + *
> + * Note: the iter_prog 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.
> + */
> +
[...]
> +
> +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_DESCENDANTS_PRE)
> + seq_puts(seq, "order: pre\n");
> + else if (aux->cgroup.order == BPF_ITER_DESCENDANTS_POST)
> + seq_puts(seq, "order: post\n");
> + else if (aux->cgroup.order == BPF_ITER_ANCESTORS_UP)
> + seq_puts(seq, "order: up\n");
> + else /* BPF_ITER_SELF */
> + seq_puts(seq, "order: self\n");
should we output "descendants_pre", "descendants_post", "ancestors_up"
and "self" to match enum names more uniformly? We had similar
discussion when Daniel Mueller was doing some clean up in bpftool and
public's opinion was that uniform and consistent mapping between
kernel enum and it's string representation is more valuable than
shortness of the string.
> +}
> +
[...]
On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
<[email protected]> wrote:
>
> On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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 <[email protected]>
> > Acked-by: Tejun Heo <[email protected]>
> > Signed-off-by: Hao Luo <[email protected]>
> > ---
> > include/linux/bpf.h | 8 +
> > include/uapi/linux/bpf.h | 38 +++
> > kernel/bpf/Makefile | 3 +
> > kernel/bpf/cgroup_iter.c | 286 ++++++++++++++++++
> > tools/include/uapi/linux/bpf.h | 38 +++
> > .../selftests/bpf/prog_tests/btf_dump.c | 4 +-
> > 6 files changed, 375 insertions(+), 2 deletions(-)
> > create mode 100644 kernel/bpf/cgroup_iter.c
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 20c26aed7896..09b5c2167424 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;
> > + } 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 59a217ca2dfd..4d758b2e70d6 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > };
> >
> > +enum bpf_iter_order {
> > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
>
> why is this default order necessary? It just adds confusion (I had to
> look up source code to know what is default order). I might have
> missed some discussion, so if there is some very good reason, then
> please document this in commit message. But I'd rather not do some
> magical default order instead. We can set 0 to mean invalid and error
> out, or just do SELF as the very first value (and if user forgot to
> specify more fancy mode, they hopefully will quickly discover this in
> their testing).
>
PRE/POST/UP are tree-specific orders. SELF applies on all iters and
yields only a single object. How does task_iter express a non-self
order? By non-self, I mean something like "I don't care about the
order, just scan _all_ the objects". And this "don't care" order, IMO,
may be the common case. I don't think everyone cares about walking
order for tasks. The DEFAULT is intentionally put at the first value,
so that if users don't care about order, they don't have to specify
this field.
If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
> > + BPF_ITER_SELF, /* process only a single object. */
> > + BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
> > + BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> > + BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> > +};
> > +
>
> This is a somewhat pedantic nit, so feel free to ignore completely,
> but don't DESCENDANTS_{PRE,POST} and ANCESTORS_UP also include "self"?
> As it is right now, BPF_ITER_SELF name might be read as implying that
> DESCENDANTS and ANCESTORS order don't include self. So I don't know,
> maybe BPF_ITER_SELF_ONLY would be a bit clearer?
>
No problem with that. I can update it in the next version.
>
> > union bpf_iter_link_info {
> > struct {
> > __u32 map_fd;
> > } map;
> > + struct {
> > + /* Valid values include:
> > + * - BPF_ITER_ORDER_DEFAULT
> > + * - BPF_ITER_SELF
> > + * - BPF_ITER_DESCENDANTS_PRE
> > + * - BPF_ITER_DESCENDANTS_POST
> > + * - BPF_ITER_ANCESTORS_UP
> > + * for cgroup_iter, DEFAULT is equivalent to DESCENDANTS_PRE.
> > + */
> > + __u32 order;
> > +
> > + /* 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;
> > + } cgroup;
> > };
> >
> > /* BPF syscall commands, see bpf(2) man-page for more details. */
> > @@ -6134,11 +6161,22 @@ struct bpf_link_info {
> > struct {
> > __aligned_u64 target_name; /* in/out: target_name buffer ptr */
> > __u32 target_name_len; /* in/out: target_name buffer len */
> > +
> > + /* If the iter specific field is 32 bits, it can be put
> > + * in the first or second union. Otherwise it should be
> > + * put in the second union.
> > + */
> > union {
> > struct {
> > __u32 map_id;
> > } map;
> > };
> > + union {
> > + struct {
> > + __u64 cgroup_id;
> > + __u32 order;
> > + } cgroup;
> > + };
> > } iter;
>
> But other than above, I like how UAPI looks like, thanks!
>
> [...]
>
> > + *
> > + * 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.
>
> typo: outputting
>
Thanks for catching. Will fix.
> > + *
> > + * Note: the iter_prog 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.
> > + */
> > +
>
> [...]
>
> > +
> > +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_DESCENDANTS_PRE)
> > + seq_puts(seq, "order: pre\n");
> > + else if (aux->cgroup.order == BPF_ITER_DESCENDANTS_POST)
> > + seq_puts(seq, "order: post\n");
> > + else if (aux->cgroup.order == BPF_ITER_ANCESTORS_UP)
> > + seq_puts(seq, "order: up\n");
> > + else /* BPF_ITER_SELF */
> > + seq_puts(seq, "order: self\n");
>
> should we output "descendants_pre", "descendants_post", "ancestors_up"
> and "self" to match enum names more uniformly? We had similar
> discussion when Daniel Mueller was doing some clean up in bpftool and
> public's opinion was that uniform and consistent mapping between
> kernel enum and it's string representation is more valuable than
> shortness of the string.
>
I feel this is very nit, but can update in the next version. On a
second thought, I think, specifying "descendants", "ancestors" and
"self" are probably slightly better. Because doing so, people know
it's a tree when reading iter link info.
> > +}
> > +
>
> [...]
On Mon, Aug 08, 2022 at 05:56:57PM -0700, Hao Luo wrote:
> On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
> <[email protected]> wrote:
> >
> > On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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 <[email protected]>
> > > Acked-by: Tejun Heo <[email protected]>
> > > Signed-off-by: Hao Luo <[email protected]>
> > > ---
> > > include/linux/bpf.h | 8 +
> > > include/uapi/linux/bpf.h | 38 +++
> > > kernel/bpf/Makefile | 3 +
> > > kernel/bpf/cgroup_iter.c | 286 ++++++++++++++++++
> > > tools/include/uapi/linux/bpf.h | 38 +++
> > > .../selftests/bpf/prog_tests/btf_dump.c | 4 +-
> > > 6 files changed, 375 insertions(+), 2 deletions(-)
> > > create mode 100644 kernel/bpf/cgroup_iter.c
> > >
> > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > > index 20c26aed7896..09b5c2167424 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;
> > > + } 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 59a217ca2dfd..4d758b2e70d6 100644
> > > --- a/include/uapi/linux/bpf.h
> > > +++ b/include/uapi/linux/bpf.h
> > > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > > };
> > >
> > > +enum bpf_iter_order {
> > > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
> >
> > why is this default order necessary? It just adds confusion (I had to
> > look up source code to know what is default order). I might have
> > missed some discussion, so if there is some very good reason, then
> > please document this in commit message. But I'd rather not do some
> > magical default order instead. We can set 0 to mean invalid and error
> > out, or just do SELF as the very first value (and if user forgot to
> > specify more fancy mode, they hopefully will quickly discover this in
> > their testing).
> >
>
> PRE/POST/UP are tree-specific orders. SELF applies on all iters and
> yields only a single object. How does task_iter express a non-self
> order? By non-self, I mean something like "I don't care about the
> order, just scan _all_ the objects". And this "don't care" order, IMO,
> may be the common case. I don't think everyone cares about walking
> order for tasks. The DEFAULT is intentionally put at the first value,
> so that if users don't care about order, they don't have to specify
> this field.
>
> If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
I agree with Andrii.
This:
+ if (order == BPF_ITER_ORDER_DEFAULT)
+ order = BPF_ITER_DESCENDANTS_PRE;
looks like an arbitrary choice.
imo
BPF_ITER_DESCENDANTS_PRE = 0,
would have been more obvious. No need to dig into definition of "default".
UNSPEC = 0
is fine too if we want user to always be conscious about the order
and the kernel will error if that field is not initialized.
That would be my preference, since it will match the rest of uapi/bpf.h
I applied the first 3 patches to ease respin.
Thanks!
On Tue, Aug 9, 2022 at 9:23 AM Alexei Starovoitov
<[email protected]> wrote:
>
> On Mon, Aug 08, 2022 at 05:56:57PM -0700, Hao Luo wrote:
> > On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
> > <[email protected]> wrote:
> > >
> > > On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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.
> > > >
[...]
> > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > index 59a217ca2dfd..4d758b2e70d6 100644
> > > > --- a/include/uapi/linux/bpf.h
> > > > +++ b/include/uapi/linux/bpf.h
> > > > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > > > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > > > };
> > > >
> > > > +enum bpf_iter_order {
> > > > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
> > >
> > > why is this default order necessary? It just adds confusion (I had to
> > > look up source code to know what is default order). I might have
> > > missed some discussion, so if there is some very good reason, then
> > > please document this in commit message. But I'd rather not do some
> > > magical default order instead. We can set 0 to mean invalid and error
> > > out, or just do SELF as the very first value (and if user forgot to
> > > specify more fancy mode, they hopefully will quickly discover this in
> > > their testing).
> > >
> >
> > PRE/POST/UP are tree-specific orders. SELF applies on all iters and
> > yields only a single object. How does task_iter express a non-self
> > order? By non-self, I mean something like "I don't care about the
> > order, just scan _all_ the objects". And this "don't care" order, IMO,
> > may be the common case. I don't think everyone cares about walking
> > order for tasks. The DEFAULT is intentionally put at the first value,
> > so that if users don't care about order, they don't have to specify
> > this field.
> >
> > If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
>
> I agree with Andrii.
> This:
> + if (order == BPF_ITER_ORDER_DEFAULT)
> + order = BPF_ITER_DESCENDANTS_PRE;
>
> looks like an arbitrary choice.
> imo
> BPF_ITER_DESCENDANTS_PRE = 0,
> would have been more obvious. No need to dig into definition of "default".
>
> UNSPEC = 0
> is fine too if we want user to always be conscious about the order
> and the kernel will error if that field is not initialized.
> That would be my preference, since it will match the rest of uapi/bpf.h
>
Sounds good. In the next version, will use
enum bpf_iter_order {
BPF_ITER_ORDER_UNSPEC = 0,
BPF_ITER_SELF_ONLY, /* process only a single object. */
BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
};
and explicitly list the values acceptable by cgroup_iter, error out if
UNSPEC is detected.
Also, following Andrii's comments, will change BPF_ITER_SELF to
BPF_ITER_SELF_ONLY, which does seem a little bit explicit in
comparison.
> I applied the first 3 patches to ease respin.
Thanks! This helps!
> Thanks!
On Tue, Aug 9, 2022 at 11:38 AM Hao Luo <[email protected]> wrote:
>
> On Tue, Aug 9, 2022 at 9:23 AM Alexei Starovoitov
> <[email protected]> wrote:
> >
> > On Mon, Aug 08, 2022 at 05:56:57PM -0700, Hao Luo wrote:
> > > On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
> > > <[email protected]> wrote:
> > > >
> > > > On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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.
> > > > >
> [...]
> > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > index 59a217ca2dfd..4d758b2e70d6 100644
> > > > > --- a/include/uapi/linux/bpf.h
> > > > > +++ b/include/uapi/linux/bpf.h
> > > > > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > > > > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > > > > };
> > > > >
> > > > > +enum bpf_iter_order {
> > > > > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
> > > >
> > > > why is this default order necessary? It just adds confusion (I had to
> > > > look up source code to know what is default order). I might have
> > > > missed some discussion, so if there is some very good reason, then
> > > > please document this in commit message. But I'd rather not do some
> > > > magical default order instead. We can set 0 to mean invalid and error
> > > > out, or just do SELF as the very first value (and if user forgot to
> > > > specify more fancy mode, they hopefully will quickly discover this in
> > > > their testing).
> > > >
> > >
> > > PRE/POST/UP are tree-specific orders. SELF applies on all iters and
> > > yields only a single object. How does task_iter express a non-self
> > > order? By non-self, I mean something like "I don't care about the
> > > order, just scan _all_ the objects". And this "don't care" order, IMO,
> > > may be the common case. I don't think everyone cares about walking
> > > order for tasks. The DEFAULT is intentionally put at the first value,
> > > so that if users don't care about order, they don't have to specify
> > > this field.
> > >
> > > If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
> >
> > I agree with Andrii.
> > This:
> > + if (order == BPF_ITER_ORDER_DEFAULT)
> > + order = BPF_ITER_DESCENDANTS_PRE;
> >
> > looks like an arbitrary choice.
> > imo
> > BPF_ITER_DESCENDANTS_PRE = 0,
> > would have been more obvious. No need to dig into definition of "default".
> >
> > UNSPEC = 0
> > is fine too if we want user to always be conscious about the order
> > and the kernel will error if that field is not initialized.
> > That would be my preference, since it will match the rest of uapi/bpf.h
> >
>
> Sounds good. In the next version, will use
>
> enum bpf_iter_order {
> BPF_ITER_ORDER_UNSPEC = 0,
> BPF_ITER_SELF_ONLY, /* process only a single object. */
> BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
> BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> };
>
Sigh, I find that having UNSPEC=0 and erroring out when seeing UNSPEC
doesn't work. Basically, if we have a non-iter prog and a cgroup_iter
prog written in the same source file, I can't use
bpf_object__attach_skeleton to attach them. Because the default
prog_attach_fn for iter initializes `order` to 0 (that is, UNSPEC),
which is going to be rejected by the kernel. In order to make
bpf_object__attach_skeleton work on cgroup_iter, I think I need to use
the following
enum bpf_iter_order {
BPF_ITER_DESCENDANTS_PRE, /* 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. */
};
So that when calling bpf_object__attach_skeleton() on cgroup_iter, a
link can be generated and the generated link defaults to pre-order
walk on the whole hierarchy. Is there a better solution?
> and explicitly list the values acceptable by cgroup_iter, error out if
> UNSPEC is detected.
>
> Also, following Andrii's comments, will change BPF_ITER_SELF to
> BPF_ITER_SELF_ONLY, which does seem a little bit explicit in
> comparison.
>
> > I applied the first 3 patches to ease respin.
>
> Thanks! This helps!
>
> > Thanks!
On Wed, Aug 10, 2022 at 8:10 PM Hao Luo <[email protected]> wrote:
>
> On Tue, Aug 9, 2022 at 11:38 AM Hao Luo <[email protected]> wrote:
> >
> > On Tue, Aug 9, 2022 at 9:23 AM Alexei Starovoitov
> > <[email protected]> wrote:
> > >
> > > On Mon, Aug 08, 2022 at 05:56:57PM -0700, Hao Luo wrote:
> > > > On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
> > > > <[email protected]> wrote:
> > > > >
> > > > > On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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.
> > > > > >
> > [...]
> > > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > > index 59a217ca2dfd..4d758b2e70d6 100644
> > > > > > --- a/include/uapi/linux/bpf.h
> > > > > > +++ b/include/uapi/linux/bpf.h
> > > > > > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > > > > > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > > > > > };
> > > > > >
> > > > > > +enum bpf_iter_order {
> > > > > > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
> > > > >
> > > > > why is this default order necessary? It just adds confusion (I had to
> > > > > look up source code to know what is default order). I might have
> > > > > missed some discussion, so if there is some very good reason, then
> > > > > please document this in commit message. But I'd rather not do some
> > > > > magical default order instead. We can set 0 to mean invalid and error
> > > > > out, or just do SELF as the very first value (and if user forgot to
> > > > > specify more fancy mode, they hopefully will quickly discover this in
> > > > > their testing).
> > > > >
> > > >
> > > > PRE/POST/UP are tree-specific orders. SELF applies on all iters and
> > > > yields only a single object. How does task_iter express a non-self
> > > > order? By non-self, I mean something like "I don't care about the
> > > > order, just scan _all_ the objects". And this "don't care" order, IMO,
> > > > may be the common case. I don't think everyone cares about walking
> > > > order for tasks. The DEFAULT is intentionally put at the first value,
> > > > so that if users don't care about order, they don't have to specify
> > > > this field.
> > > >
> > > > If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
> > >
> > > I agree with Andrii.
> > > This:
> > > + if (order == BPF_ITER_ORDER_DEFAULT)
> > > + order = BPF_ITER_DESCENDANTS_PRE;
> > >
> > > looks like an arbitrary choice.
> > > imo
> > > BPF_ITER_DESCENDANTS_PRE = 0,
> > > would have been more obvious. No need to dig into definition of "default".
> > >
> > > UNSPEC = 0
> > > is fine too if we want user to always be conscious about the order
> > > and the kernel will error if that field is not initialized.
> > > That would be my preference, since it will match the rest of uapi/bpf.h
> > >
> >
> > Sounds good. In the next version, will use
> >
> > enum bpf_iter_order {
> > BPF_ITER_ORDER_UNSPEC = 0,
> > BPF_ITER_SELF_ONLY, /* process only a single object. */
> > BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
> > BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> > BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> > };
> >
>
> Sigh, I find that having UNSPEC=0 and erroring out when seeing UNSPEC
> doesn't work. Basically, if we have a non-iter prog and a cgroup_iter
> prog written in the same source file, I can't use
> bpf_object__attach_skeleton to attach them. Because the default
> prog_attach_fn for iter initializes `order` to 0 (that is, UNSPEC),
> which is going to be rejected by the kernel. In order to make
> bpf_object__attach_skeleton work on cgroup_iter, I think I need to use
> the following
>
> enum bpf_iter_order {
> BPF_ITER_DESCENDANTS_PRE, /* 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. */
> };
>
> So that when calling bpf_object__attach_skeleton() on cgroup_iter, a
> link can be generated and the generated link defaults to pre-order
> walk on the whole hierarchy. Is there a better solution?
>
I think this can be handled by userspace? We can attach the
cgroup_iter separately first (and maybe we will need to set prog->link
as well) so that bpf_object__attach_skeleton() doesn't try to attach
it? I am following this pattern in the selftest in the final patch,
although I think I might be missing setting prog->link, so I am
wondering why there are no issues in that selftest which has the same
scenario that you are talking about.
I think such a pattern will need to be used anyway if the users need
to set any non-default arguments for the cgroup_iter prog (like the
selftest), right? The only case we are discussing here is the case
where the user wants to attach the cgroup_iter with all default
options (in which case the default order will fail).
I agree that it might be inconvenient if the default/uninitialized
options don't work for cgroup_iter, but Alexei pointed out that this
matches other bpf uapis.
My concern is that in the future we try to reuse enum bpf_iter_order
to set ordering for other iterators, and then the
default/uninitialized value (BPF_ITER_DESCENDANTS_PRE) doesn't make
sense for that iterator (e.g. not a tree). In this case, the same
problem that we are avoiding for cgroup_iter here will show up for
that iterator, and we can't easily change it at this point because
it's uapi.
> > and explicitly list the values acceptable by cgroup_iter, error out if
> > UNSPEC is detected.
> >
> > Also, following Andrii's comments, will change BPF_ITER_SELF to
> > BPF_ITER_SELF_ONLY, which does seem a little bit explicit in
> > comparison.
> >
> > > I applied the first 3 patches to ease respin.
> >
> > Thanks! This helps!
> >
> > > Thanks!
On Mon, Aug 15, 2022 at 9:12 PM Andrii Nakryiko
<[email protected]> wrote:
>
> On Thu, Aug 11, 2022 at 7:10 AM Yosry Ahmed <[email protected]> wrote:
> >
> > On Wed, Aug 10, 2022 at 8:10 PM Hao Luo <[email protected]> wrote:
> > >
> > > On Tue, Aug 9, 2022 at 11:38 AM Hao Luo <[email protected]> wrote:
> > > >
> > > > On Tue, Aug 9, 2022 at 9:23 AM Alexei Starovoitov
> > > > <[email protected]> wrote:
> > > > >
> > > > > On Mon, Aug 08, 2022 at 05:56:57PM -0700, Hao Luo wrote:
> > > > > > On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
> > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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.
> > > > > > > >
> > > > [...]
> > > > > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > > > > index 59a217ca2dfd..4d758b2e70d6 100644
> > > > > > > > --- a/include/uapi/linux/bpf.h
> > > > > > > > +++ b/include/uapi/linux/bpf.h
> > > > > > > > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > > > > > > > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > > > > > > > };
> > > > > > > >
> > > > > > > > +enum bpf_iter_order {
> > > > > > > > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
> > > > > > >
> > > > > > > why is this default order necessary? It just adds confusion (I had to
> > > > > > > look up source code to know what is default order). I might have
> > > > > > > missed some discussion, so if there is some very good reason, then
> > > > > > > please document this in commit message. But I'd rather not do some
> > > > > > > magical default order instead. We can set 0 to mean invalid and error
> > > > > > > out, or just do SELF as the very first value (and if user forgot to
> > > > > > > specify more fancy mode, they hopefully will quickly discover this in
> > > > > > > their testing).
> > > > > > >
> > > > > >
> > > > > > PRE/POST/UP are tree-specific orders. SELF applies on all iters and
> > > > > > yields only a single object. How does task_iter express a non-self
> > > > > > order? By non-self, I mean something like "I don't care about the
> > > > > > order, just scan _all_ the objects". And this "don't care" order, IMO,
> > > > > > may be the common case. I don't think everyone cares about walking
> > > > > > order for tasks. The DEFAULT is intentionally put at the first value,
> > > > > > so that if users don't care about order, they don't have to specify
> > > > > > this field.
> > > > > >
> > > > > > If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
> > > > >
> > > > > I agree with Andrii.
> > > > > This:
> > > > > + if (order == BPF_ITER_ORDER_DEFAULT)
> > > > > + order = BPF_ITER_DESCENDANTS_PRE;
> > > > >
> > > > > looks like an arbitrary choice.
> > > > > imo
> > > > > BPF_ITER_DESCENDANTS_PRE = 0,
> > > > > would have been more obvious. No need to dig into definition of "default".
> > > > >
> > > > > UNSPEC = 0
> > > > > is fine too if we want user to always be conscious about the order
> > > > > and the kernel will error if that field is not initialized.
> > > > > That would be my preference, since it will match the rest of uapi/bpf.h
> > > > >
> > > >
> > > > Sounds good. In the next version, will use
> > > >
> > > > enum bpf_iter_order {
> > > > BPF_ITER_ORDER_UNSPEC = 0,
> > > > BPF_ITER_SELF_ONLY, /* process only a single object. */
> > > > BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
> > > > BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> > > > BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> > > > };
> > > >
> > >
> > > Sigh, I find that having UNSPEC=0 and erroring out when seeing UNSPEC
> > > doesn't work. Basically, if we have a non-iter prog and a cgroup_iter
> > > prog written in the same source file, I can't use
> > > bpf_object__attach_skeleton to attach them. Because the default
> > > prog_attach_fn for iter initializes `order` to 0 (that is, UNSPEC),
> > > which is going to be rejected by the kernel. In order to make
> > > bpf_object__attach_skeleton work on cgroup_iter, I think I need to use
> > > the following
> > >
> > > enum bpf_iter_order {
>
> so first of all, this can't be called "bpf_iter_order" as it doesn't
> apply to BPF iterators in general. I think this should be called
> bpf_iter_cgroup_order (or maybe bpf_cgroup_iter_order) and if/when we
> add ability to iterate tasks within cgroups then we'll just reuse enum
> bpf_iter_cgroup_order as an extra parameter for task iterator.
>
> And with that future case in mind I do think that we should have 0
> being "UNSPEC" case.
>
> > > BPF_ITER_DESCENDANTS_PRE, /* 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. */
> > > };
> > >
> > > So that when calling bpf_object__attach_skeleton() on cgroup_iter, a
> > > link can be generated and the generated link defaults to pre-order
> > > walk on the whole hierarchy. Is there a better solution?
> > >
>
> I was actually surprised that we specify these additional parameters
> at attach (LINK_CREATE) time, and not at bpf_iter_create() call time.
> It seems more appropriate to allow to specify such runtime parameters
> very late, when we create a specific instance of seq_file. But I guess
> this was done because one of the initial motivations for iterators was
> to be pinned in BPFFS and read as a file, so it was more convenient to
> store such parameters upfront at link creation time to keep
> BPF_OBJ_PIN simpler. I guess it makes sense, worst case you'll need to
> create multiple bpf_link files, one for each cgroup hierarchy you'd
> like to query with the same single BPF program.
>
> But I digress.
>
> As for not being able to auto-attach cgroup iterator. I think that's
> sort of expected and is in line with not being able to auto-attach
> cgroup programs, as you need cgroup FD at runtime. So even if you had
> some reasonable default order, you still would need to specify target
> cgroup (either through FD or ID).
>
> So... either don't do skeleton auto-attach, or let's teach libbpf code
> to not auto-attach some iter types?
>
> Alternatively, we could teach libbpf to parse some sort of cgroup
> iterator spec, like:
>
> SEC("iter/cgroup:/path/to/cgroup:descendants_pre")
>
> But this approach won't work for a bunch of other parameterized
> iterators (e.g., task iter, or map elem iter), so I'm hesitant about
> adding this to libbpf as a generic functionality.
As yet another alternative (given you seem to default to root cgroup
when cgroup_fd or cgroup_id is not specified), we can teach libbpf to
just specify BPF_ITER_DESCENDANTS_PRE (or whichever mode seems like
best default) only for auto-attach case. If that makes most sense.
>
> >
> > I think this can be handled by userspace? We can attach the
> > cgroup_iter separately first (and maybe we will need to set prog->link
> > as well) so that bpf_object__attach_skeleton() doesn't try to attach
> > it? I am following this pattern in the selftest in the final patch,
> > although I think I might be missing setting prog->link, so I am
> > wondering why there are no issues in that selftest which has the same
> > scenario that you are talking about.
> >
> > I think such a pattern will need to be used anyway if the users need
> > to set any non-default arguments for the cgroup_iter prog (like the
> > selftest), right? The only case we are discussing here is the case
> > where the user wants to attach the cgroup_iter with all default
> > options (in which case the default order will fail).
> > I agree that it might be inconvenient if the default/uninitialized
> > options don't work for cgroup_iter, but Alexei pointed out that this
> > matches other bpf uapis.
> >
> > My concern is that in the future we try to reuse enum bpf_iter_order
> > to set ordering for other iterators, and then the
> > default/uninitialized value (BPF_ITER_DESCENDANTS_PRE) doesn't make
> > sense for that iterator (e.g. not a tree). In this case, the same
> > problem that we are avoiding for cgroup_iter here will show up for
> > that iterator, and we can't easily change it at this point because
> > it's uapi.
>
> Yep, valid concern, I agree.
>
> >
> >
> > > > and explicitly list the values acceptable by cgroup_iter, error out if
> > > > UNSPEC is detected.
> > > >
> > > > Also, following Andrii's comments, will change BPF_ITER_SELF to
> > > > BPF_ITER_SELF_ONLY, which does seem a little bit explicit in
> > > > comparison.
> > > >
> > > > > I applied the first 3 patches to ease respin.
> > > >
> > > > Thanks! This helps!
> > > >
> > > > > Thanks!
On Thu, Aug 11, 2022 at 7:10 AM Yosry Ahmed <[email protected]> wrote:
>
> On Wed, Aug 10, 2022 at 8:10 PM Hao Luo <[email protected]> wrote:
> >
> > On Tue, Aug 9, 2022 at 11:38 AM Hao Luo <[email protected]> wrote:
> > >
> > > On Tue, Aug 9, 2022 at 9:23 AM Alexei Starovoitov
> > > <[email protected]> wrote:
> > > >
> > > > On Mon, Aug 08, 2022 at 05:56:57PM -0700, Hao Luo wrote:
> > > > > On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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.
> > > > > > >
> > > [...]
> > > > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > > > index 59a217ca2dfd..4d758b2e70d6 100644
> > > > > > > --- a/include/uapi/linux/bpf.h
> > > > > > > +++ b/include/uapi/linux/bpf.h
> > > > > > > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > > > > > > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > > > > > > };
> > > > > > >
> > > > > > > +enum bpf_iter_order {
> > > > > > > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
> > > > > >
> > > > > > why is this default order necessary? It just adds confusion (I had to
> > > > > > look up source code to know what is default order). I might have
> > > > > > missed some discussion, so if there is some very good reason, then
> > > > > > please document this in commit message. But I'd rather not do some
> > > > > > magical default order instead. We can set 0 to mean invalid and error
> > > > > > out, or just do SELF as the very first value (and if user forgot to
> > > > > > specify more fancy mode, they hopefully will quickly discover this in
> > > > > > their testing).
> > > > > >
> > > > >
> > > > > PRE/POST/UP are tree-specific orders. SELF applies on all iters and
> > > > > yields only a single object. How does task_iter express a non-self
> > > > > order? By non-self, I mean something like "I don't care about the
> > > > > order, just scan _all_ the objects". And this "don't care" order, IMO,
> > > > > may be the common case. I don't think everyone cares about walking
> > > > > order for tasks. The DEFAULT is intentionally put at the first value,
> > > > > so that if users don't care about order, they don't have to specify
> > > > > this field.
> > > > >
> > > > > If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
> > > >
> > > > I agree with Andrii.
> > > > This:
> > > > + if (order == BPF_ITER_ORDER_DEFAULT)
> > > > + order = BPF_ITER_DESCENDANTS_PRE;
> > > >
> > > > looks like an arbitrary choice.
> > > > imo
> > > > BPF_ITER_DESCENDANTS_PRE = 0,
> > > > would have been more obvious. No need to dig into definition of "default".
> > > >
> > > > UNSPEC = 0
> > > > is fine too if we want user to always be conscious about the order
> > > > and the kernel will error if that field is not initialized.
> > > > That would be my preference, since it will match the rest of uapi/bpf.h
> > > >
> > >
> > > Sounds good. In the next version, will use
> > >
> > > enum bpf_iter_order {
> > > BPF_ITER_ORDER_UNSPEC = 0,
> > > BPF_ITER_SELF_ONLY, /* process only a single object. */
> > > BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
> > > BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> > > BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> > > };
> > >
> >
> > Sigh, I find that having UNSPEC=0 and erroring out when seeing UNSPEC
> > doesn't work. Basically, if we have a non-iter prog and a cgroup_iter
> > prog written in the same source file, I can't use
> > bpf_object__attach_skeleton to attach them. Because the default
> > prog_attach_fn for iter initializes `order` to 0 (that is, UNSPEC),
> > which is going to be rejected by the kernel. In order to make
> > bpf_object__attach_skeleton work on cgroup_iter, I think I need to use
> > the following
> >
> > enum bpf_iter_order {
so first of all, this can't be called "bpf_iter_order" as it doesn't
apply to BPF iterators in general. I think this should be called
bpf_iter_cgroup_order (or maybe bpf_cgroup_iter_order) and if/when we
add ability to iterate tasks within cgroups then we'll just reuse enum
bpf_iter_cgroup_order as an extra parameter for task iterator.
And with that future case in mind I do think that we should have 0
being "UNSPEC" case.
> > BPF_ITER_DESCENDANTS_PRE, /* 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. */
> > };
> >
> > So that when calling bpf_object__attach_skeleton() on cgroup_iter, a
> > link can be generated and the generated link defaults to pre-order
> > walk on the whole hierarchy. Is there a better solution?
> >
I was actually surprised that we specify these additional parameters
at attach (LINK_CREATE) time, and not at bpf_iter_create() call time.
It seems more appropriate to allow to specify such runtime parameters
very late, when we create a specific instance of seq_file. But I guess
this was done because one of the initial motivations for iterators was
to be pinned in BPFFS and read as a file, so it was more convenient to
store such parameters upfront at link creation time to keep
BPF_OBJ_PIN simpler. I guess it makes sense, worst case you'll need to
create multiple bpf_link files, one for each cgroup hierarchy you'd
like to query with the same single BPF program.
But I digress.
As for not being able to auto-attach cgroup iterator. I think that's
sort of expected and is in line with not being able to auto-attach
cgroup programs, as you need cgroup FD at runtime. So even if you had
some reasonable default order, you still would need to specify target
cgroup (either through FD or ID).
So... either don't do skeleton auto-attach, or let's teach libbpf code
to not auto-attach some iter types?
Alternatively, we could teach libbpf to parse some sort of cgroup
iterator spec, like:
SEC("iter/cgroup:/path/to/cgroup:descendants_pre")
But this approach won't work for a bunch of other parameterized
iterators (e.g., task iter, or map elem iter), so I'm hesitant about
adding this to libbpf as a generic functionality.
>
> I think this can be handled by userspace? We can attach the
> cgroup_iter separately first (and maybe we will need to set prog->link
> as well) so that bpf_object__attach_skeleton() doesn't try to attach
> it? I am following this pattern in the selftest in the final patch,
> although I think I might be missing setting prog->link, so I am
> wondering why there are no issues in that selftest which has the same
> scenario that you are talking about.
>
> I think such a pattern will need to be used anyway if the users need
> to set any non-default arguments for the cgroup_iter prog (like the
> selftest), right? The only case we are discussing here is the case
> where the user wants to attach the cgroup_iter with all default
> options (in which case the default order will fail).
> I agree that it might be inconvenient if the default/uninitialized
> options don't work for cgroup_iter, but Alexei pointed out that this
> matches other bpf uapis.
>
> My concern is that in the future we try to reuse enum bpf_iter_order
> to set ordering for other iterators, and then the
> default/uninitialized value (BPF_ITER_DESCENDANTS_PRE) doesn't make
> sense for that iterator (e.g. not a tree). In this case, the same
> problem that we are avoiding for cgroup_iter here will show up for
> that iterator, and we can't easily change it at this point because
> it's uapi.
Yep, valid concern, I agree.
>
>
> > > and explicitly list the values acceptable by cgroup_iter, error out if
> > > UNSPEC is detected.
> > >
> > > Also, following Andrii's comments, will change BPF_ITER_SELF to
> > > BPF_ITER_SELF_ONLY, which does seem a little bit explicit in
> > > comparison.
> > >
> > > > I applied the first 3 patches to ease respin.
> > >
> > > Thanks! This helps!
> > >
> > > > Thanks!
On Mon, Aug 15, 2022 at 9:13 PM Andrii Nakryiko
<[email protected]> wrote:
>
> On Thu, Aug 11, 2022 at 7:10 AM Yosry Ahmed <[email protected]> wrote:
> >
> > On Wed, Aug 10, 2022 at 8:10 PM Hao Luo <[email protected]> wrote:
> > >
> > > On Tue, Aug 9, 2022 at 11:38 AM Hao Luo <[email protected]> wrote:
> > > >
> > > > On Tue, Aug 9, 2022 at 9:23 AM Alexei Starovoitov
> > > > <[email protected]> wrote:
> > > > >
> > > > > On Mon, Aug 08, 2022 at 05:56:57PM -0700, Hao Luo wrote:
> > > > > > On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
> > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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.
> > > > > > > >
> > > > [...]
> > > > > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > > > > index 59a217ca2dfd..4d758b2e70d6 100644
> > > > > > > > --- a/include/uapi/linux/bpf.h
> > > > > > > > +++ b/include/uapi/linux/bpf.h
> > > > > > > > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > > > > > > > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > > > > > > > };
> > > > > > > >
> > > > > > > > +enum bpf_iter_order {
> > > > > > > > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
> > > > > > >
> > > > > > > why is this default order necessary? It just adds confusion (I had to
> > > > > > > look up source code to know what is default order). I might have
> > > > > > > missed some discussion, so if there is some very good reason, then
> > > > > > > please document this in commit message. But I'd rather not do some
> > > > > > > magical default order instead. We can set 0 to mean invalid and error
> > > > > > > out, or just do SELF as the very first value (and if user forgot to
> > > > > > > specify more fancy mode, they hopefully will quickly discover this in
> > > > > > > their testing).
> > > > > > >
> > > > > >
> > > > > > PRE/POST/UP are tree-specific orders. SELF applies on all iters and
> > > > > > yields only a single object. How does task_iter express a non-self
> > > > > > order? By non-self, I mean something like "I don't care about the
> > > > > > order, just scan _all_ the objects". And this "don't care" order, IMO,
> > > > > > may be the common case. I don't think everyone cares about walking
> > > > > > order for tasks. The DEFAULT is intentionally put at the first value,
> > > > > > so that if users don't care about order, they don't have to specify
> > > > > > this field.
> > > > > >
> > > > > > If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
> > > > >
> > > > > I agree with Andrii.
> > > > > This:
> > > > > + if (order == BPF_ITER_ORDER_DEFAULT)
> > > > > + order = BPF_ITER_DESCENDANTS_PRE;
> > > > >
> > > > > looks like an arbitrary choice.
> > > > > imo
> > > > > BPF_ITER_DESCENDANTS_PRE = 0,
> > > > > would have been more obvious. No need to dig into definition of "default".
> > > > >
> > > > > UNSPEC = 0
> > > > > is fine too if we want user to always be conscious about the order
> > > > > and the kernel will error if that field is not initialized.
> > > > > That would be my preference, since it will match the rest of uapi/bpf.h
> > > > >
> > > >
> > > > Sounds good. In the next version, will use
> > > >
> > > > enum bpf_iter_order {
> > > > BPF_ITER_ORDER_UNSPEC = 0,
> > > > BPF_ITER_SELF_ONLY, /* process only a single object. */
> > > > BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
> > > > BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> > > > BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> > > > };
> > > >
> > >
> > > Sigh, I find that having UNSPEC=0 and erroring out when seeing UNSPEC
> > > doesn't work. Basically, if we have a non-iter prog and a cgroup_iter
> > > prog written in the same source file, I can't use
> > > bpf_object__attach_skeleton to attach them. Because the default
> > > prog_attach_fn for iter initializes `order` to 0 (that is, UNSPEC),
> > > which is going to be rejected by the kernel. In order to make
> > > bpf_object__attach_skeleton work on cgroup_iter, I think I need to use
> > > the following
> > >
> > > enum bpf_iter_order {
>
> so first of all, this can't be called "bpf_iter_order" as it doesn't
> apply to BPF iterators in general. I think this should be called
> bpf_iter_cgroup_order (or maybe bpf_cgroup_iter_order) and if/when we
> add ability to iterate tasks within cgroups then we'll just reuse enum
> bpf_iter_cgroup_order as an extra parameter for task iterator.
>
> And with that future case in mind I do think that we should have 0
> being "UNSPEC" case.
>
Ok.
> > > BPF_ITER_DESCENDANTS_PRE, /* 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. */
> > > };
> > >
> > > So that when calling bpf_object__attach_skeleton() on cgroup_iter, a
> > > link can be generated and the generated link defaults to pre-order
> > > walk on the whole hierarchy. Is there a better solution?
> > >
>
> I was actually surprised that we specify these additional parameters
> at attach (LINK_CREATE) time, and not at bpf_iter_create() call time.
> It seems more appropriate to allow to specify such runtime parameters
> very late, when we create a specific instance of seq_file. But I guess
> this was done because one of the initial motivations for iterators was
> to be pinned in BPFFS and read as a file, so it was more convenient to
> store such parameters upfront at link creation time to keep
> BPF_OBJ_PIN simpler. I guess it makes sense, worst case you'll need to
> create multiple bpf_link files, one for each cgroup hierarchy you'd
> like to query with the same single BPF program.
>
Right. That was the design from the beginning.
> But I digress.
>
> As for not being able to auto-attach cgroup iterator. I think that's
> sort of expected and is in line with not being able to auto-attach
> cgroup programs, as you need cgroup FD at runtime. So even if you had
> some reasonable default order, you still would need to specify target
> cgroup (either through FD or ID).
>
> So... either don't do skeleton auto-attach,
This is not okay IMHO. It would be very inconvenient to use.
> or let's teach libbpf code
> to not auto-attach some iter types?
>
I'm thinking of two options:
1. Maybe we could add libbpf APIs for disabling auto-attach just like
prog autoload. Like:
bpf_program__set_auto_attach()
bpf_program__get_auto_attach(...)
2. In auto-attach, if the program's link is already set, attach will
be skipped. So, we could just manually attach, which specifies the
order, and set the link in skeleton. This way, no change in libbpf is
needed. Does this sound good to you?
> Alternatively, we could teach libbpf to parse some sort of cgroup
> iterator spec, like:
>
> SEC("iter/cgroup:/path/to/cgroup:descendants_pre")
>
> But this approach won't work for a bunch of other parameterized
> iterators (e.g., task iter, or map elem iter), so I'm hesitant about
> adding this to libbpf as a generic functionality.
>
Agree. Let's explore other options first.
> >
> > I think this can be handled by userspace? We can attach the
> > cgroup_iter separately first (and maybe we will need to set prog->link
> > as well) so that bpf_object__attach_skeleton() doesn't try to attach
> > it? I am following this pattern in the selftest in the final patch,
> > although I think I might be missing setting prog->link, so I am
> > wondering why there are no issues in that selftest which has the same
> > scenario that you are talking about.
> >
> > I think such a pattern will need to be used anyway if the users need
> > to set any non-default arguments for the cgroup_iter prog (like the
> > selftest), right? The only case we are discussing here is the case
> > where the user wants to attach the cgroup_iter with all default
> > options (in which case the default order will fail).
> > I agree that it might be inconvenient if the default/uninitialized
> > options don't work for cgroup_iter, but Alexei pointed out that this
> > matches other bpf uapis.
> >
> > My concern is that in the future we try to reuse enum bpf_iter_order
> > to set ordering for other iterators, and then the
> > default/uninitialized value (BPF_ITER_DESCENDANTS_PRE) doesn't make
> > sense for that iterator (e.g. not a tree). In this case, the same
> > problem that we are avoiding for cgroup_iter here will show up for
> > that iterator, and we can't easily change it at this point because
> > it's uapi.
>
> Yep, valid concern, I agree.
>
Andrii, other than auto-attach, do you have any concern for the rest
of this patchset?
> >
> >
> > > > and explicitly list the values acceptable by cgroup_iter, error out if
> > > > UNSPEC is detected.
> > > >
> > > > Also, following Andrii's comments, will change BPF_ITER_SELF to
> > > > BPF_ITER_SELF_ONLY, which does seem a little bit explicit in
> > > > comparison.
> > > >
> > > > > I applied the first 3 patches to ease respin.
> > > >
> > > > Thanks! This helps!
> > > >
> > > > > Thanks!
On Tue, Aug 16, 2022 at 10:17 AM Andrii Nakryiko
<[email protected]> wrote:
>
> On Mon, Aug 15, 2022 at 11:52 PM Hao Luo <[email protected]> wrote:
> >
> > On Mon, Aug 15, 2022 at 9:13 PM Andrii Nakryiko
> > <[email protected]> wrote:
> > >
> > > On Thu, Aug 11, 2022 at 7:10 AM Yosry Ahmed <[email protected]> wrote:
> > > >
> > > > On Wed, Aug 10, 2022 at 8:10 PM Hao Luo <[email protected]> wrote:
> > > > >
> > > > > On Tue, Aug 9, 2022 at 11:38 AM Hao Luo <[email protected]> wrote:
> > > > > >
> > > > > > On Tue, Aug 9, 2022 at 9:23 AM Alexei Starovoitov
> > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > On Mon, Aug 08, 2022 at 05:56:57PM -0700, Hao Luo wrote:
> > > > > > > > On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
> > > > > > > > <[email protected]> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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.
> > > > > > > > > >
> > > > > > [...]
> > > > > > > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > > > > > > index 59a217ca2dfd..4d758b2e70d6 100644
> > > > > > > > > > --- a/include/uapi/linux/bpf.h
> > > > > > > > > > +++ b/include/uapi/linux/bpf.h
> > > > > > > > > > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > > > > > > > > > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > +enum bpf_iter_order {
> > > > > > > > > > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
> > > > > > > > >
> > > > > > > > > why is this default order necessary? It just adds confusion (I had to
> > > > > > > > > look up source code to know what is default order). I might have
> > > > > > > > > missed some discussion, so if there is some very good reason, then
> > > > > > > > > please document this in commit message. But I'd rather not do some
> > > > > > > > > magical default order instead. We can set 0 to mean invalid and error
> > > > > > > > > out, or just do SELF as the very first value (and if user forgot to
> > > > > > > > > specify more fancy mode, they hopefully will quickly discover this in
> > > > > > > > > their testing).
> > > > > > > > >
> > > > > > > >
> > > > > > > > PRE/POST/UP are tree-specific orders. SELF applies on all iters and
> > > > > > > > yields only a single object. How does task_iter express a non-self
> > > > > > > > order? By non-self, I mean something like "I don't care about the
> > > > > > > > order, just scan _all_ the objects". And this "don't care" order, IMO,
> > > > > > > > may be the common case. I don't think everyone cares about walking
> > > > > > > > order for tasks. The DEFAULT is intentionally put at the first value,
> > > > > > > > so that if users don't care about order, they don't have to specify
> > > > > > > > this field.
> > > > > > > >
> > > > > > > > If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
> > > > > > >
> > > > > > > I agree with Andrii.
> > > > > > > This:
> > > > > > > + if (order == BPF_ITER_ORDER_DEFAULT)
> > > > > > > + order = BPF_ITER_DESCENDANTS_PRE;
> > > > > > >
> > > > > > > looks like an arbitrary choice.
> > > > > > > imo
> > > > > > > BPF_ITER_DESCENDANTS_PRE = 0,
> > > > > > > would have been more obvious. No need to dig into definition of "default".
> > > > > > >
> > > > > > > UNSPEC = 0
> > > > > > > is fine too if we want user to always be conscious about the order
> > > > > > > and the kernel will error if that field is not initialized.
> > > > > > > That would be my preference, since it will match the rest of uapi/bpf.h
> > > > > > >
> > > > > >
> > > > > > Sounds good. In the next version, will use
> > > > > >
> > > > > > enum bpf_iter_order {
> > > > > > BPF_ITER_ORDER_UNSPEC = 0,
> > > > > > BPF_ITER_SELF_ONLY, /* process only a single object. */
> > > > > > BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
> > > > > > BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> > > > > > BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> > > > > > };
> > > > > >
> > > > >
> > > > > Sigh, I find that having UNSPEC=0 and erroring out when seeing UNSPEC
> > > > > doesn't work. Basically, if we have a non-iter prog and a cgroup_iter
> > > > > prog written in the same source file, I can't use
> > > > > bpf_object__attach_skeleton to attach them. Because the default
> > > > > prog_attach_fn for iter initializes `order` to 0 (that is, UNSPEC),
> > > > > which is going to be rejected by the kernel. In order to make
> > > > > bpf_object__attach_skeleton work on cgroup_iter, I think I need to use
> > > > > the following
> > > > >
> > > > > enum bpf_iter_order {
> > >
> > > so first of all, this can't be called "bpf_iter_order" as it doesn't
> > > apply to BPF iterators in general. I think this should be called
> > > bpf_iter_cgroup_order (or maybe bpf_cgroup_iter_order) and if/when we
> > > add ability to iterate tasks within cgroups then we'll just reuse enum
> > > bpf_iter_cgroup_order as an extra parameter for task iterator.
> > >
> > > And with that future case in mind I do think that we should have 0
> > > being "UNSPEC" case.
> > >
> >
> > Ok.
> >
> > > > > BPF_ITER_DESCENDANTS_PRE, /* 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. */
> > > > > };
> > > > >
> > > > > So that when calling bpf_object__attach_skeleton() on cgroup_iter, a
> > > > > link can be generated and the generated link defaults to pre-order
> > > > > walk on the whole hierarchy. Is there a better solution?
> > > > >
> > >
> > > I was actually surprised that we specify these additional parameters
> > > at attach (LINK_CREATE) time, and not at bpf_iter_create() call time.
> > > It seems more appropriate to allow to specify such runtime parameters
> > > very late, when we create a specific instance of seq_file. But I guess
> > > this was done because one of the initial motivations for iterators was
> > > to be pinned in BPFFS and read as a file, so it was more convenient to
> > > store such parameters upfront at link creation time to keep
> > > BPF_OBJ_PIN simpler. I guess it makes sense, worst case you'll need to
> > > create multiple bpf_link files, one for each cgroup hierarchy you'd
> > > like to query with the same single BPF program.
> > >
> >
> > Right. That was the design from the beginning.
> >
> > > But I digress.
> > >
> > > As for not being able to auto-attach cgroup iterator. I think that's
> > > sort of expected and is in line with not being able to auto-attach
> > > cgroup programs, as you need cgroup FD at runtime. So even if you had
> > > some reasonable default order, you still would need to specify target
> > > cgroup (either through FD or ID).
> > >
> > > So... either don't do skeleton auto-attach,
> >
> > This is not okay IMHO. It would be very inconvenient to use.
> >
> > > or let's teach libbpf code
> > > to not auto-attach some iter types?
> > >
> >
> > I'm thinking of two options:
> >
> > 1. Maybe we could add libbpf APIs for disabling auto-attach just like
> > prog autoload. Like:
> >
> > bpf_program__set_auto_attach()
> > bpf_program__get_auto_attach(...)
>
> Indeed, to give more flexibility we can also add
> bpf_program__set_autoattach() and bpf_program__autoattach() (note no
> underscore and no get prefix, to be consistent with autocreate and
> autoload getters and setters). It's a pretty simple change, please
> send a separate patch for this (soon-ish would be great to make it
> into final 1.0).
Acknowledged.
> >
> > 2. In auto-attach, if the program's link is already set, attach will
> > be skipped. So, we could just manually attach, which specifies the
> > order, and set the link in skeleton. This way, no change in libbpf is
> > needed. Does this sound good to you?
> >
>
> Yes, this is one other way and is fully supported. Might be a bit less
> convenient than set_autoattach in some cases, so set_autoattach still
> makes sense, IMO.
>
Acknowledged.
> > > Alternatively, we could teach libbpf to parse some sort of cgroup
> > > iterator spec, like:
> > >
> > > SEC("iter/cgroup:/path/to/cgroup:descendants_pre")
> > >
> > > But this approach won't work for a bunch of other parameterized
> > > iterators (e.g., task iter, or map elem iter), so I'm hesitant about
> > > adding this to libbpf as a generic functionality.
> > >
> >
> > Agree. Let's explore other options first.
> >
> > > >
> > > > I think this can be handled by userspace? We can attach the
> > > > cgroup_iter separately first (and maybe we will need to set prog->link
> > > > as well) so that bpf_object__attach_skeleton() doesn't try to attach
> > > > it? I am following this pattern in the selftest in the final patch,
> > > > although I think I might be missing setting prog->link, so I am
> > > > wondering why there are no issues in that selftest which has the same
> > > > scenario that you are talking about.
> > > >
> > > > I think such a pattern will need to be used anyway if the users need
> > > > to set any non-default arguments for the cgroup_iter prog (like the
> > > > selftest), right? The only case we are discussing here is the case
> > > > where the user wants to attach the cgroup_iter with all default
> > > > options (in which case the default order will fail).
> > > > I agree that it might be inconvenient if the default/uninitialized
> > > > options don't work for cgroup_iter, but Alexei pointed out that this
> > > > matches other bpf uapis.
> > > >
> > > > My concern is that in the future we try to reuse enum bpf_iter_order
> > > > to set ordering for other iterators, and then the
> > > > default/uninitialized value (BPF_ITER_DESCENDANTS_PRE) doesn't make
> > > > sense for that iterator (e.g. not a tree). In this case, the same
> > > > problem that we are avoiding for cgroup_iter here will show up for
> > > > that iterator, and we can't easily change it at this point because
> > > > it's uapi.
> > >
> > > Yep, valid concern, I agree.
> > >
> >
> > Andrii, other than auto-attach, do you have any concern for the rest
> > of this patchset?
>
> Well, I mostly was looking at UAPIs, didn't check iteration logic
> itself. But plenty of others did and I trust they did a good job at
> that. So no, no other concerns.
>
Thanks Andrii, I will try to send set_autoattach and autoattach patch asap.
> >
> > > >
> > > >
> > > > > > and explicitly list the values acceptable by cgroup_iter, error out if
> > > > > > UNSPEC is detected.
> > > > > >
> > > > > > Also, following Andrii's comments, will change BPF_ITER_SELF to
> > > > > > BPF_ITER_SELF_ONLY, which does seem a little bit explicit in
> > > > > > comparison.
> > > > > >
> > > > > > > I applied the first 3 patches to ease respin.
> > > > > >
> > > > > > Thanks! This helps!
> > > > > >
> > > > > > > Thanks!
On Mon, Aug 15, 2022 at 11:52 PM Hao Luo <[email protected]> wrote:
>
> On Mon, Aug 15, 2022 at 9:13 PM Andrii Nakryiko
> <[email protected]> wrote:
> >
> > On Thu, Aug 11, 2022 at 7:10 AM Yosry Ahmed <[email protected]> wrote:
> > >
> > > On Wed, Aug 10, 2022 at 8:10 PM Hao Luo <[email protected]> wrote:
> > > >
> > > > On Tue, Aug 9, 2022 at 11:38 AM Hao Luo <[email protected]> wrote:
> > > > >
> > > > > On Tue, Aug 9, 2022 at 9:23 AM Alexei Starovoitov
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On Mon, Aug 08, 2022 at 05:56:57PM -0700, Hao Luo wrote:
> > > > > > > On Mon, Aug 8, 2022 at 5:19 PM Andrii Nakryiko
> > > > > > > <[email protected]> wrote:
> > > > > > > >
> > > > > > > > On Fri, Aug 5, 2022 at 2:49 PM Hao Luo <[email protected]> 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.
> > > > > > > > >
> > > > > [...]
> > > > > > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > > > > > index 59a217ca2dfd..4d758b2e70d6 100644
> > > > > > > > > --- a/include/uapi/linux/bpf.h
> > > > > > > > > +++ b/include/uapi/linux/bpf.h
> > > > > > > > > @@ -87,10 +87,37 @@ struct bpf_cgroup_storage_key {
> > > > > > > > > __u32 attach_type; /* program attach type (enum bpf_attach_type) */
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > +enum bpf_iter_order {
> > > > > > > > > + BPF_ITER_ORDER_DEFAULT = 0, /* default order. */
> > > > > > > >
> > > > > > > > why is this default order necessary? It just adds confusion (I had to
> > > > > > > > look up source code to know what is default order). I might have
> > > > > > > > missed some discussion, so if there is some very good reason, then
> > > > > > > > please document this in commit message. But I'd rather not do some
> > > > > > > > magical default order instead. We can set 0 to mean invalid and error
> > > > > > > > out, or just do SELF as the very first value (and if user forgot to
> > > > > > > > specify more fancy mode, they hopefully will quickly discover this in
> > > > > > > > their testing).
> > > > > > > >
> > > > > > >
> > > > > > > PRE/POST/UP are tree-specific orders. SELF applies on all iters and
> > > > > > > yields only a single object. How does task_iter express a non-self
> > > > > > > order? By non-self, I mean something like "I don't care about the
> > > > > > > order, just scan _all_ the objects". And this "don't care" order, IMO,
> > > > > > > may be the common case. I don't think everyone cares about walking
> > > > > > > order for tasks. The DEFAULT is intentionally put at the first value,
> > > > > > > so that if users don't care about order, they don't have to specify
> > > > > > > this field.
> > > > > > >
> > > > > > > If that sounds valid, maybe using "UNSPEC" instead of "DEFAULT" is better?
> > > > > >
> > > > > > I agree with Andrii.
> > > > > > This:
> > > > > > + if (order == BPF_ITER_ORDER_DEFAULT)
> > > > > > + order = BPF_ITER_DESCENDANTS_PRE;
> > > > > >
> > > > > > looks like an arbitrary choice.
> > > > > > imo
> > > > > > BPF_ITER_DESCENDANTS_PRE = 0,
> > > > > > would have been more obvious. No need to dig into definition of "default".
> > > > > >
> > > > > > UNSPEC = 0
> > > > > > is fine too if we want user to always be conscious about the order
> > > > > > and the kernel will error if that field is not initialized.
> > > > > > That would be my preference, since it will match the rest of uapi/bpf.h
> > > > > >
> > > > >
> > > > > Sounds good. In the next version, will use
> > > > >
> > > > > enum bpf_iter_order {
> > > > > BPF_ITER_ORDER_UNSPEC = 0,
> > > > > BPF_ITER_SELF_ONLY, /* process only a single object. */
> > > > > BPF_ITER_DESCENDANTS_PRE, /* walk descendants in pre-order. */
> > > > > BPF_ITER_DESCENDANTS_POST, /* walk descendants in post-order. */
> > > > > BPF_ITER_ANCESTORS_UP, /* walk ancestors upward. */
> > > > > };
> > > > >
> > > >
> > > > Sigh, I find that having UNSPEC=0 and erroring out when seeing UNSPEC
> > > > doesn't work. Basically, if we have a non-iter prog and a cgroup_iter
> > > > prog written in the same source file, I can't use
> > > > bpf_object__attach_skeleton to attach them. Because the default
> > > > prog_attach_fn for iter initializes `order` to 0 (that is, UNSPEC),
> > > > which is going to be rejected by the kernel. In order to make
> > > > bpf_object__attach_skeleton work on cgroup_iter, I think I need to use
> > > > the following
> > > >
> > > > enum bpf_iter_order {
> >
> > so first of all, this can't be called "bpf_iter_order" as it doesn't
> > apply to BPF iterators in general. I think this should be called
> > bpf_iter_cgroup_order (or maybe bpf_cgroup_iter_order) and if/when we
> > add ability to iterate tasks within cgroups then we'll just reuse enum
> > bpf_iter_cgroup_order as an extra parameter for task iterator.
> >
> > And with that future case in mind I do think that we should have 0
> > being "UNSPEC" case.
> >
>
> Ok.
>
> > > > BPF_ITER_DESCENDANTS_PRE, /* 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. */
> > > > };
> > > >
> > > > So that when calling bpf_object__attach_skeleton() on cgroup_iter, a
> > > > link can be generated and the generated link defaults to pre-order
> > > > walk on the whole hierarchy. Is there a better solution?
> > > >
> >
> > I was actually surprised that we specify these additional parameters
> > at attach (LINK_CREATE) time, and not at bpf_iter_create() call time.
> > It seems more appropriate to allow to specify such runtime parameters
> > very late, when we create a specific instance of seq_file. But I guess
> > this was done because one of the initial motivations for iterators was
> > to be pinned in BPFFS and read as a file, so it was more convenient to
> > store such parameters upfront at link creation time to keep
> > BPF_OBJ_PIN simpler. I guess it makes sense, worst case you'll need to
> > create multiple bpf_link files, one for each cgroup hierarchy you'd
> > like to query with the same single BPF program.
> >
>
> Right. That was the design from the beginning.
>
> > But I digress.
> >
> > As for not being able to auto-attach cgroup iterator. I think that's
> > sort of expected and is in line with not being able to auto-attach
> > cgroup programs, as you need cgroup FD at runtime. So even if you had
> > some reasonable default order, you still would need to specify target
> > cgroup (either through FD or ID).
> >
> > So... either don't do skeleton auto-attach,
>
> This is not okay IMHO. It would be very inconvenient to use.
>
> > or let's teach libbpf code
> > to not auto-attach some iter types?
> >
>
> I'm thinking of two options:
>
> 1. Maybe we could add libbpf APIs for disabling auto-attach just like
> prog autoload. Like:
>
> bpf_program__set_auto_attach()
> bpf_program__get_auto_attach(...)
Indeed, to give more flexibility we can also add
bpf_program__set_autoattach() and bpf_program__autoattach() (note no
underscore and no get prefix, to be consistent with autocreate and
autoload getters and setters). It's a pretty simple change, please
send a separate patch for this (soon-ish would be great to make it
into final 1.0).
>
> 2. In auto-attach, if the program's link is already set, attach will
> be skipped. So, we could just manually attach, which specifies the
> order, and set the link in skeleton. This way, no change in libbpf is
> needed. Does this sound good to you?
>
Yes, this is one other way and is fully supported. Might be a bit less
convenient than set_autoattach in some cases, so set_autoattach still
makes sense, IMO.
> > Alternatively, we could teach libbpf to parse some sort of cgroup
> > iterator spec, like:
> >
> > SEC("iter/cgroup:/path/to/cgroup:descendants_pre")
> >
> > But this approach won't work for a bunch of other parameterized
> > iterators (e.g., task iter, or map elem iter), so I'm hesitant about
> > adding this to libbpf as a generic functionality.
> >
>
> Agree. Let's explore other options first.
>
> > >
> > > I think this can be handled by userspace? We can attach the
> > > cgroup_iter separately first (and maybe we will need to set prog->link
> > > as well) so that bpf_object__attach_skeleton() doesn't try to attach
> > > it? I am following this pattern in the selftest in the final patch,
> > > although I think I might be missing setting prog->link, so I am
> > > wondering why there are no issues in that selftest which has the same
> > > scenario that you are talking about.
> > >
> > > I think such a pattern will need to be used anyway if the users need
> > > to set any non-default arguments for the cgroup_iter prog (like the
> > > selftest), right? The only case we are discussing here is the case
> > > where the user wants to attach the cgroup_iter with all default
> > > options (in which case the default order will fail).
> > > I agree that it might be inconvenient if the default/uninitialized
> > > options don't work for cgroup_iter, but Alexei pointed out that this
> > > matches other bpf uapis.
> > >
> > > My concern is that in the future we try to reuse enum bpf_iter_order
> > > to set ordering for other iterators, and then the
> > > default/uninitialized value (BPF_ITER_DESCENDANTS_PRE) doesn't make
> > > sense for that iterator (e.g. not a tree). In this case, the same
> > > problem that we are avoiding for cgroup_iter here will show up for
> > > that iterator, and we can't easily change it at this point because
> > > it's uapi.
> >
> > Yep, valid concern, I agree.
> >
>
> Andrii, other than auto-attach, do you have any concern for the rest
> of this patchset?
Well, I mostly was looking at UAPIs, didn't check iteration logic
itself. But plenty of others did and I trust they did a good job at
that. So no, no other concerns.
>
> > >
> > >
> > > > > and explicitly list the values acceptable by cgroup_iter, error out if
> > > > > UNSPEC is detected.
> > > > >
> > > > > Also, following Andrii's comments, will change BPF_ITER_SELF to
> > > > > BPF_ITER_SELF_ONLY, which does seem a little bit explicit in
> > > > > comparison.
> > > > >
> > > > > > I applied the first 3 patches to ease respin.
> > > > >
> > > > > Thanks! This helps!
> > > > >
> > > > > > Thanks!