[PATCH bpf-next v2 0/3] bpf: expose cgroup preorder attachment state to userspace

[PATCH bpf-next v2 0/3] bpf: expose cgroup preorder attachment state to userspace

[Hui Su]

Commit 4b82b181a26c ("bpf: Allow pre-ordering for bpf cgroup progs")
introduced BPF_F_PREORDER to request top-down (ancestor to descendant)
execution ordering across the cgroup hierarchy. While this flag is stored
in struct bpf_prog_list::flags and affects the effective program ordering,
direct BPF_PROG_QUERY currently reports only the cgroup-wide flags and
omits BPF_F_PREORDER from prog_attach_flags[].

This series extends direct cgroup program queries to expose the per-program
BPF_F_PREORDER state, adds selftests to validate the reported flags, and
updates bpftool to support inspection, attachment, documentation, and bash
completion.

Structure of the series:
- Patch 1 extends __cgroup_bpf_query() so that prog_attach_flags[] includes
  BPF_F_PREORDER for direct queries.
- Patch 2 adds query verification to cgroup_mprog_opts selftests for both
  direct program and bpf_link attachments.
- Patch 3 updates bpftool with bitmask attach flag formatting, preorder
  attachment CLI support, bash completion for valid flag combinations,
  and documentation.

Testing:
- Verified that baseline kernel reports 0x2 for PREORDER multi-attachments
  through BPF_PROG_QUERY.
- Verified that the patched kernel reports 0x42 (BPF_F_ALLOW_MULTI |
  BPF_F_PREORDER).
- Selftests cgroup_mprog_opts (all subtests) and cgroup_preorder pass in an
  x86_64 QEMU/KVM guest.
- bpftool and its documentation build cleanly without warnings or errors.
- Bash completion verified for standalone and composite flag combinations.
- checkpatch.pl reports 0 errors and 0 warnings across all patches.

Changes in v2:
- Rebase onto bpf-next and drop the Fixes tag, as requested by
  Alexei Starovoitov.
- Document the userspace-visible BPF_PROG_QUERY flag extension.
- Factor the duplicated PREORDER query checks and fix comment style.
- Clarify PREORDER ordering and single/multi attachment semantics.
- Fix bash completion for valid PREORDER flag combinations.

Hui Su (3):
  bpf: Report BPF_F_PREORDER in cgroup program queries
  selftests/bpf: Test querying BPF_F_PREORDER cgroup attachments
  bpftool: Add support for BPF_F_PREORDER cgroup attach flag

 kernel/bpf/cgroup.c                           | 16 ++---
 .../bpftool/Documentation/bpftool-cgroup.rst  | 25 ++++---
 tools/bpf/bpftool/bash-completion/bpftool     |  4 +-
 tools/bpf/bpftool/cgroup.c                    | 55 +++++++++-----
 .../bpf/prog_tests/cgroup_mprog_opts.c        | 72 ++++++++++++++++++-
 5 files changed, 134 insertions(+), 38 deletions(-)

-- 
2.55.0

[PATCH bpf-next v2 1/3] bpf: Report BPF_F_PREORDER in cgroup program queries

[Hui Su]

Commit 4b82b181a26c ("bpf: Allow pre-ordering for bpf cgroup progs")
introduced BPF_F_PREORDER to request pre-order execution across the
cgroup hierarchy, altering the effective prog array ordering.

While pl->flags stores BPF_F_PREORDER for each attached program,
__cgroup_bpf_query() currently does not report it. When querying
attached programs (!effective_query), __cgroup_bpf_query() fills
prog_attach_flags[] with cgrp->bpf.flags[atype] for all entries,
omitting the per-program BPF_F_PREORDER attribute.

Extend direct cgroup program queries to merge (pl->flags & BPF_F_PREORDER)
with the cgroup-wide flags when copying prog_attach_flags to user space.
Only BPF_F_PREORDER is extracted from pl->flags to ensure transient
positioning flags (such as BPF_F_BEFORE, BPF_F_AFTER, BPF_F_ID, or
BPF_F_REPLACE) are not leaked to user space. Also perform both ID and
attach flags copies within the same hlist iteration.

This extends prog_attach_flags[] with the per-program BPF_F_PREORDER bit.
This can introduce new prog_attach_flags[] values with BPF_F_PREORDER set,
for example 0x40 (BPF_F_PREORDER), 0x41 (BPF_F_ALLOW_OVERRIDE |
BPF_F_PREORDER), or 0x42 (BPF_F_ALLOW_MULTI | BPF_F_PREORDER) depending
on the cgroup-wide attachment mode.

Older bpftool versions treat such combinations as unknown flags; bpftool
support is updated later in this series.

Signed-off-by: Hui Su <sh_def@163.com>
---
 kernel/bpf/cgroup.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 696b27383974..eb9e0985ac43 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -1515,19 +1515,19 @@ static int __cgroup_bpf_query(struct cgroup *cgrp, const union bpf_attr *attr,
 				id = prog_list_id(pl);
 				if (copy_to_user(prog_ids + i, &id, sizeof(id)))
 					return -EFAULT;
+				if (prog_attach_flags) {
+					flags = cgrp->bpf.flags[atype] |
+						(pl->flags & BPF_F_PREORDER);
+					if (copy_to_user(prog_attach_flags + i,
+							 &flags, sizeof(flags)))
+						return -EFAULT;
+				}
 				if (++i == cnt)
 					break;
 			}
 
-			if (prog_attach_flags) {
-				flags = cgrp->bpf.flags[atype];
-
-				for (i = 0; i < cnt; i++)
-					if (copy_to_user(prog_attach_flags + i,
-							 &flags, sizeof(flags)))
-						return -EFAULT;
+			if (prog_attach_flags)
 				prog_attach_flags += cnt;
-			}
 		}
 
 		prog_ids += cnt;
-- 
2.55.0

[PATCH bpf-next v2 2/3] selftests/bpf: Test querying BPF_F_PREORDER cgroup attachments

[Hui Su]

Extend cgroup_mprog_opts selftests to verify that BPF_PROG_QUERY reports
BPF_F_PREORDER in prog_attach_flags for both direct program and link
attachments.

Specifically, add assert_preorder_query_flags() and use it from
test_preorder_prog_attach_detach() and
test_preorder_link_attach_detach() to verify that:
- Programs attached with BPF_F_PREORDER report
  BPF_F_ALLOW_MULTI | BPF_F_PREORDER (0x42) in prog_attach_flags.
- Programs attached without BPF_F_PREORDER report BPF_F_ALLOW_MULTI (0x2).
- Transient flags such as BPF_F_AFTER or BPF_F_LINK are not present in
  prog_attach_flags.
- Per-program attach flags are validated by matching each attached prog_id
  via a query helper, avoiding fragile assumptions on the internal slot
  order of the direct query list.
- Failures during prog_id lookup are guarded so uninitialized flag values
  do not trigger secondary assertion failures.

Signed-off-by: Hui Su <sh_def@163.com>
---
 .../bpf/prog_tests/cgroup_mprog_opts.c        | 72 ++++++++++++++++++-
 1 file changed, 70 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/cgroup_mprog_opts.c b/tools/testing/selftests/bpf/prog_tests/cgroup_mprog_opts.c
index bb60704a3ef9..9c706d2e61db 100644
--- a/tools/testing/selftests/bpf/prog_tests/cgroup_mprog_opts.c
+++ b/tools/testing/selftests/bpf/prog_tests/cgroup_mprog_opts.c
@@ -273,11 +273,65 @@ static void test_link_attach_detach(int atype)
 	close(cg);
 }
 
+static int find_prog_attach_flags(const struct bpf_prog_query_opts *opts,
+				  __u32 prog_id, __u32 *flags)
+{
+	__u32 i;
+
+	for (i = 0; i < opts->count; i++) {
+		if (opts->prog_ids[i] == prog_id) {
+			*flags = opts->prog_attach_flags[i];
+			return 0;
+		}
+	}
+	return -ENOENT;
+}
+
+static void assert_preorder_query_flags(int cg, int atype,
+					__u32 id1, __u32 id2,
+					__u32 id3, __u32 id4)
+{
+	LIBBPF_OPTS(bpf_prog_query_opts, optq);
+	__u32 prog_attach_flags[10] = {};
+	__u32 prog_ids[10] = {};
+	__u32 flags;
+	int err;
+
+	optq.prog_ids = prog_ids;
+	optq.prog_attach_flags = prog_attach_flags;
+	optq.count = 10;
+	err = bpf_prog_query_opts(cg, atype, &optq);
+	if (!ASSERT_OK(err, "prog_query"))
+		return;
+
+	ASSERT_EQ(optq.count, 4, "count");
+
+	/*
+	 * Direct query reports attached programs in cgroup list order.
+	 * Lookup by prog_id to verify per-program flags independently of slot index.
+	 */
+	err = find_prog_attach_flags(&optq, id1, &flags);
+	if (ASSERT_OK(err, "find id1"))
+		ASSERT_EQ(flags, BPF_F_ALLOW_MULTI, "flags id1");
+
+	err = find_prog_attach_flags(&optq, id2, &flags);
+	if (ASSERT_OK(err, "find id2"))
+		ASSERT_EQ(flags, BPF_F_ALLOW_MULTI | BPF_F_PREORDER, "flags id2");
+
+	err = find_prog_attach_flags(&optq, id3, &flags);
+	if (ASSERT_OK(err, "find id3"))
+		ASSERT_EQ(flags, BPF_F_ALLOW_MULTI | BPF_F_PREORDER, "flags id3");
+
+	err = find_prog_attach_flags(&optq, id4, &flags);
+	if (ASSERT_OK(err, "find id4"))
+		ASSERT_EQ(flags, BPF_F_ALLOW_MULTI, "flags id4");
+}
+
 static void test_preorder_prog_attach_detach(int atype)
 {
 	LIBBPF_OPTS(bpf_prog_attach_opts, opta);
 	LIBBPF_OPTS(bpf_prog_detach_opts, optd);
-	__u32 fd1, fd2, fd3, fd4;
+	__u32 fd1, fd2, fd3, fd4, id1, id2, id3, id4;
 	struct cgroup_mprog *skel;
 	int cg, err;
 
@@ -294,6 +348,11 @@ static void test_preorder_prog_attach_detach(int atype)
 	fd3 = bpf_program__fd(skel->progs.getsockopt_3);
 	fd4 = bpf_program__fd(skel->progs.getsockopt_4);
 
+	id1 = id_from_prog_fd(fd1);
+	id2 = id_from_prog_fd(fd2);
+	id3 = id_from_prog_fd(fd3);
+	id4 = id_from_prog_fd(fd4);
+
 	assert_mprog_count(cg, atype, 0);
 
 	LIBBPF_OPTS_RESET(opta,
@@ -357,6 +416,8 @@ static void test_preorder_prog_attach_detach(int atype)
 
 	assert_mprog_count(cg, atype, 4);
 
+	assert_preorder_query_flags(cg, atype, id1, id2, id3, id4);
+
 	err = bpf_prog_detach_opts(fd4, cg, atype, &optd);
 	ASSERT_OK(err, "prog_detach");
 	assert_mprog_count(cg, atype, 3);
@@ -386,7 +447,7 @@ static void test_preorder_link_attach_detach(int atype)
 	LIBBPF_OPTS(bpf_cgroup_opts, opta);
 	struct bpf_link *link1, *link2, *link3, *link4;
 	struct cgroup_mprog *skel;
-	__u32 fd2;
+	__u32 fd2, id1, id2, id3, id4;
 	int cg;
 
 	cg = test__join_cgroup("/preorder_link_attach_detach");
@@ -399,6 +460,11 @@ static void test_preorder_link_attach_detach(int atype)
 
 	fd2 = bpf_program__fd(skel->progs.getsockopt_2);
 
+	id1 = id_from_prog_fd(bpf_program__fd(skel->progs.getsockopt_1));
+	id2 = id_from_prog_fd(fd2);
+	id3 = id_from_prog_fd(bpf_program__fd(skel->progs.getsockopt_3));
+	id4 = id_from_prog_fd(bpf_program__fd(skel->progs.getsockopt_4));
+
 	assert_mprog_count(cg, atype, 0);
 
 	LIBBPF_OPTS_RESET(opta,
@@ -460,6 +526,8 @@ static void test_preorder_link_attach_detach(int atype)
 
 	assert_mprog_count(cg, atype, 4);
 
+	assert_preorder_query_flags(cg, atype, id1, id2, id3, id4);
+
 	bpf_link__destroy(link4);
 	assert_mprog_count(cg, atype, 3);
 
-- 
2.55.0

[PATCH bpf-next v2 3/3] bpftool: Add support for BPF_F_PREORDER cgroup attach flag

[Hui Su]

Commit 4b82b181a26c ("bpf: Allow pre-ordering for bpf cgroup progs")
introduced BPF_F_PREORDER to request pre-order execution across the
cgroup hierarchy. Furthermore, attachments legitimately use combinations
such as BPF_F_ALLOW_MULTI | BPF_F_PREORDER or
BPF_F_ALLOW_OVERRIDE | BPF_F_PREORDER.

With BPF_PROG_QUERY reporting the per-program BPF_F_PREORDER attribute,
bpftool's exact-match formatter falls back to "unknown(40)" when
BPF_F_PREORDER is present alone, or "unknown(41)" / "unknown(42)" when
combined with BPF_F_ALLOW_OVERRIDE or BPF_F_ALLOW_MULTI. Additionally,
do_attach() only accepts "multi" and "override", rejecting "preorder" with
"unknown option".

Before:
  $ bpftool cgroup show <cg>
  1234  cgroup_inet_ingress  unknown(42)  test_prog
  $ bpftool cgroup attach <cg> cgroup_inet_ingress id 5678 multi preorder
  Error: unknown option: preorder

After:
  $ bpftool cgroup show <cg>
  1234  cgroup_inet_ingress  multi,preorder  test_prog
  $ bpftool cgroup attach <cg> cgroup_inet_ingress id 5678 multi preorder
  (attaches successfully)

Refactor the attach flags formatter into a bitmask formatter that outputs
comma-separated flag names while preserving unrecognized bits as
"unknown(...)". Accept "preorder" in do_attach(), update the cgroup
documentation and synopsis to express valid flag combinations, and teach
bash completion about them ("multi" or "override" optionally combined with
"preorder").

Signed-off-by: Hui Su <sh_def@163.com>
---
 .../bpftool/Documentation/bpftool-cgroup.rst  | 25 ++++++---
 tools/bpf/bpftool/bash-completion/bpftool     |  4 +-
 tools/bpf/bpftool/cgroup.c                    | 55 +++++++++++++------
 3 files changed, 56 insertions(+), 28 deletions(-)

diff --git a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
index e8185596a759..f8408ed44d74 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
@@ -45,7 +45,7 @@ CGROUP COMMANDS
 |     **cgroup_unix_recvmsg** | **cgroup_sysctl** |
 |     **cgroup_getsockopt** | **cgroup_setsockopt** |
 |     **cgroup_inet_sock_release** }
-| *ATTACH_FLAGS* := { **multi** | **override** }
+| *ATTACH_FLAGS* := { **multi** [ **preorder** ] | **override** [ **preorder** ] | **preorder** }
 
 DESCRIPTION
 ===========
@@ -75,20 +75,27 @@ bpftool cgroup attach *CGROUP* *ATTACH_TYPE* *PROG* [*ATTACH_FLAGS*]
     Attach program *PROG* to the cgroup *CGROUP* with attach type *ATTACH_TYPE*
     and optional *ATTACH_FLAGS*.
 
-    *ATTACH_FLAGS* can be one of: **override** if a sub-cgroup installs some
+    *ATTACH_FLAGS* can include: **override** if a sub-cgroup installs some
     bpf program, the program in this cgroup yields to sub-cgroup program;
     **multi** if a sub-cgroup installs some bpf program, that cgroup program
-    gets run in addition to the program in this cgroup.
+    gets run in addition to the program in this cgroup;
+    **preorder** requests that this program executes in ancestor-to-descendant
+    order before non-preorder descendants-to-ancestors programs during evaluation
+    across the cgroup hierarchy. Note that **preorder** alone does not enable
+    multi-program attachment; specify **multi** together with **preorder** to
+    attach multiple programs.
 
-    Only one program is allowed to be attached to a cgroup with no attach flags
-    or the **override** flag. Attaching another program will release old
-    program and attach the new one.
+    Only one program is allowed to be attached to a cgroup unless the
+    **multi** flag is specified. Without **multi**, attaching another program
+    replaces the existing program, provided the **override** setting matches.
 
     Multiple programs are allowed to be attached to a cgroup with **multi**.
-    They are executed in FIFO order (those that were attached first, run
-    first).
+    Programs marked with **preorder** are placed before non-preorder programs
+    in the effective program array. Within each ordering class at the same
+    cgroup level, attachment order is preserved.
 
-    Non-default *ATTACH_FLAGS* are supported by kernel version 4.14 and later.
+    **multi** and **override** are supported by kernel version 4.14 and later.
+    **preorder** was introduced upstream in Linux 6.15.
 
     *ATTACH_TYPE* can be one of:
 
diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
index 75cbcb512eba..a51c68029e16 100644
--- a/tools/bpf/bpftool/bash-completion/bpftool
+++ b/tools/bpf/bpftool/bash-completion/bpftool
@@ -1057,7 +1057,6 @@ _bpftool()
                 attach|detach)
                     local BPFTOOL_CGROUP_ATTACH_TYPES="$(bpftool feature list_builtins attach_types 2>/dev/null | \
                         grep '^cgroup_')"
-                    local ATTACH_FLAGS='multi override'
                     # Check for $prev = $command first
                     if [ $prev = $command ]; then
                         _filedir
@@ -1087,7 +1086,8 @@ _bpftool()
                                 # "id|pinned|tag|name" (we already checked for
                                 # that). This should only leave the case when
                                 # we need attach flags for "attach" commamnd.
-                                _bpftool_one_of_list "$ATTACH_FLAGS"
+                                _bpftool_one_of_list 'multi override'
+                                _bpftool_once_attr 'preorder'
                             fi
                             return 0
                             ;;
diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
index ce69d1e5468e..6ea0492ea532 100644
--- a/tools/bpf/bpftool/cgroup.c
+++ b/tools/bpf/bpftool/cgroup.c
@@ -56,7 +56,7 @@ static const int cgroup_attach_types[] = {
 };
 
 #define HELP_SPEC_ATTACH_FLAGS						\
-	"ATTACH_FLAGS := { multi | override }"
+	"ATTACH_FLAGS := { multi [ preorder ] | override [ preorder ] | preorder }"
 
 #define HELP_SPEC_ATTACH_TYPES						\
 	"       ATTACH_TYPE := { cgroup_inet_ingress | cgroup_inet_egress |\n" \
@@ -269,6 +269,39 @@ static int show_effective_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
 	return 0;
 }
 
+static const char *format_attach_flags(__u32 attach_flags, char *buf, size_t sz)
+{
+	static const struct {
+		__u32 flag;
+		const char *name;
+	} flags[] = {
+		{ BPF_F_ALLOW_MULTI, "multi" },
+		{ BPF_F_ALLOW_OVERRIDE, "override" },
+		{ BPF_F_PREORDER, "preorder" },
+	};
+	size_t len = 0;
+	size_t i;
+	int n;
+
+	buf[0] = '\0';
+	for (i = 0; i < ARRAY_SIZE(flags); i++) {
+		if (attach_flags & flags[i].flag) {
+			n = snprintf(buf + len, sz - len, "%s%s",
+				     len ? "," : "", flags[i].name);
+			if (n < 0 || (size_t)n >= sz - len)
+				return buf;
+			len += n;
+			attach_flags &= ~flags[i].flag;
+		}
+	}
+
+	if (attach_flags)
+		snprintf(buf + len, sz - len, "%sunknown(%x)",
+			 len ? "," : "", attach_flags);
+
+	return buf;
+}
+
 static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
 				   int level)
 {
@@ -276,7 +309,7 @@ static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
 	__u32 prog_attach_flags[1024] = {0};
 	const char *attach_flags_str;
 	__u32 prog_ids[1024] = {0};
-	char buf[32];
+	char buf[64];
 	__u32 iter;
 	int ret;
 
@@ -296,21 +329,7 @@ static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
 		__u32 attach_flags;
 
 		attach_flags = prog_attach_flags[iter] ?: p.attach_flags;
-
-		switch (attach_flags) {
-		case BPF_F_ALLOW_MULTI:
-			attach_flags_str = "multi";
-			break;
-		case BPF_F_ALLOW_OVERRIDE:
-			attach_flags_str = "override";
-			break;
-		case 0:
-			attach_flags_str = "";
-			break;
-		default:
-			snprintf(buf, sizeof(buf), "unknown(%x)", attach_flags);
-			attach_flags_str = buf;
-		}
+		attach_flags_str = format_attach_flags(attach_flags, buf, sizeof(buf));
 
 		show_bpf_prog(prog_ids[iter], type,
 			      attach_flags_str, level);
@@ -593,6 +612,8 @@ static int do_attach(int argc, char **argv)
 			attach_flags |= BPF_F_ALLOW_MULTI;
 		} else if (is_prefix(argv[i], "override")) {
 			attach_flags |= BPF_F_ALLOW_OVERRIDE;
+		} else if (is_prefix(argv[i], "preorder")) {
+			attach_flags |= BPF_F_PREORDER;
 		} else {
 			p_err("unknown option: %s", argv[i]);
 			goto exit_cgroup;
-- 
2.55.0

Re: [PATCH bpf-next v2 2/3] selftests/bpf: Test querying BPF_F_PREORDER cgroup attachments

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

> selftests/bpf: Test querying BPF_F_PREORDER cgroup attachments
>
> Extend cgroup_mprog_opts selftests to verify that BPF_PROG_QUERY reports
> BPF_F_PREORDER in prog_attach_flags for both direct program and link
> attachments.
>
> Specifically, add assert_preorder_query_flags() and use it from
> test_preorder_prog_attach_detach() and
> test_preorder_link_attach_detach() to verify that:
> - Programs attached with BPF_F_PREORDER report
>   BPF_F_ALLOW_MULTI | BPF_F_PREORDER (0x42) in prog_attach_flags.
> - Programs attached without BPF_F_PREORDER report BPF_F_ALLOW_MULTI (0x2).
> - Transient flags such as BPF_F_AFTER or BPF_F_LINK are not present in
>   prog_attach_flags.
> - Per-program attach flags are validated by matching each attached prog_id
>   via a query helper, avoiding fragile assumptions on the internal slot
>   order of the direct query list.
> - Failures during prog_id lookup are guarded so uninitialized flag values
>   do not trigger secondary assertion failures.
>
> Signed-off-by: Hui Su <sh_def@163.com>

This isn't a bug, but could the last two bullets be dropped so the
changelog stays on what behaviour is now covered, rather than describing
how the test helper is written?

The first three bullets state which behaviour the new test covers, which
is the useful part. The last two bullets describe how the test code is
written (a lookup helper instead of indexing, and guarding the lookup
return before reading the flags variable) rather than what kernel
behaviour is being pinned down; that detail is visible in the diff
itself.


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35436378806

Re: [PATCH bpf-next v2 1/3] bpf: Report BPF_F_PREORDER in cgroup program queries

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

> commit a51463b14defa13db013ab6b988af5e53ffa136f
> Author: Hui Su <sh_def@163.com>
>
>     bpf: Report BPF_F_PREORDER in cgroup program queries
>
>     Commit 4b82b181a26c ("bpf: Allow pre-ordering for bpf cgroup progs")
>     introduced BPF_F_PREORDER to request pre-order execution across the
>     cgroup hierarchy, altering the effective prog array ordering.
>
>     While pl->flags stores BPF_F_PREORDER for each attached program,
>     __cgroup_bpf_query() currently does not report it. When querying
>     attached programs (!effective_query), __cgroup_bpf_query() fills
>     prog_attach_flags[] with cgrp->bpf.flags[atype] for all entries,
>     omitting the per-program BPF_F_PREORDER attribute.
>
>     Extend direct cgroup program queries to merge (pl->flags & BPF_F_PREORDER)
>     with the cgroup-wide flags when copying prog_attach_flags to user space.
>     Only BPF_F_PREORDER is extracted from pl->flags to ensure transient
>     positioning flags (such as BPF_F_BEFORE, BPF_F_AFTER, BPF_F_ID, or
>     BPF_F_REPLACE) are not leaked to user space. Also perform both ID and
>     attach flags copies within the same hlist iteration.
>
>     This extends prog_attach_flags[] with the per-program BPF_F_PREORDER bit.

This isn't a bug, but could the changelog drop the duplicated sentence?
The paragraph starting with "Extend direct cgroup program queries to
merge (pl->flags & BPF_F_PREORDER) with the cgroup-wide flags..." and
the following sentence "This extends prog_attach_flags[] with the
per-program BPF_F_PREORDER bit." say the same thing.

Also, does the line "Also perform both ID and attach flags copies within
the same hlist iteration." add information that isn't already visible in
the diff?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35436378806

Re: [PATCH bpf-next v2 3/3] bpftool: Add support for BPF_F_PREORDER cgroup attach flag

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 4335 bytes --]

> diff --git a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
> index e8185596a759b..f8408ed44d748 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst

[ ... ]

> diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
> index 75cbcb512ebae..a51c68029e16f 100644
> --- a/tools/bpf/bpftool/bash-completion/bpftool
> +++ b/tools/bpf/bpftool/bash-completion/bpftool

[ ... ]

> diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
> index ce69d1e5468e3..6ea0492ea5327 100644
> --- a/tools/bpf/bpftool/cgroup.c
> +++ b/tools/bpf/bpftool/cgroup.c
> @@ -56,7 +56,7 @@ static const int cgroup_attach_types[] = {
>  };
>
>  #define HELP_SPEC_ATTACH_FLAGS						\
> -	"ATTACH_FLAGS := { multi | override }"
> +	"ATTACH_FLAGS := { multi [ preorder ] | override [ preorder ] | preorder }"

[ ... ]

> @@ -269,6 +269,39 @@ static int show_effective_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
>  	return 0;
>  }
>
> +static const char *format_attach_flags(__u32 attach_flags, char *buf, size_t sz)
> +{
> +	static const struct {
> +		__u32 flag;
> +		const char *name;
> +	} flags[] = {
> +		{ BPF_F_ALLOW_MULTI, "multi" },
> +		{ BPF_F_ALLOW_OVERRIDE, "override" },
> +		{ BPF_F_PREORDER, "preorder" },
> +	};
> +	size_t len = 0;
> +	size_t i;
> +	int n;
> +
> +	buf[0] = '\0';
> +	for (i = 0; i < ARRAY_SIZE(flags); i++) {
> +		if (attach_flags & flags[i].flag) {
> +			n = snprintf(buf + len, sz - len, "%s%s",
> +				     len ? "," : "", flags[i].name);
> +			if (n < 0 || (size_t)n >= sz - len)
> +				return buf;
> +			len += n;
> +			attach_flags &= ~flags[i].flag;
> +		}
> +	}
> +
> +	if (attach_flags)
> +		snprintf(buf + len, sz - len, "%sunknown(%x)",
> +			 len ? "," : "", attach_flags);
> +
> +	return buf;
> +}
> +
>  static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
>  				   int level)
>  {
> @@ -276,7 +309,7 @@ static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
>  	__u32 prog_attach_flags[1024] = {0};
>  	const char *attach_flags_str;
>  	__u32 prog_ids[1024] = {0};
> -	char buf[32];
> +	char buf[64];
>  	__u32 iter;
>  	int ret;
>
> @@ -296,21 +329,7 @@ static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
>  		__u32 attach_flags;
>
>  		attach_flags = prog_attach_flags[iter] ?: p.attach_flags;
> -
> -		switch (attach_flags) {
> -		case BPF_F_ALLOW_MULTI:
> -			attach_flags_str = "multi";
> -			break;
> -		case BPF_F_ALLOW_OVERRIDE:
> -			attach_flags_str = "override";
> -			break;
> -		case 0:
> -			attach_flags_str = "";
> -			break;
> -		default:
> -			snprintf(buf, sizeof(buf), "unknown(%x)", attach_flags);
> -			attach_flags_str = buf;
> -		}
> +		attach_flags_str = format_attach_flags(attach_flags, buf, sizeof(buf));
>
>  		show_bpf_prog(prog_ids[iter], type,
>  			      attach_flags_str, level);

Can the comma-separated flag strings here misalign the Name column?

The new formatter produces strings like "override,preorder" (17 chars) and
"multi,override,preorder" (23 chars), but the plain-text output table in
do_show() and do_show_tree() formats the AttachFlags column with %-15s:

    printf("%-8s %-15s %-15s %-15s\n", "ID", "AttachType",
           "AttachFlags", "Name");

and show_bpf_prog() uses the same width:

    printf(" %-15s %-15s", attach_flags_str, prog_name);

Since %-15s doesn't truncate, strings exceeding 15 characters will push
the Name column to the right for those rows. Before this patch, the same
attachments displayed as "unknown(41)" or "unknown(42)", which fit within
15 characters.

> @@ -593,6 +612,8 @@ static int do_attach(int argc, char **argv)
>  			attach_flags |= BPF_F_ALLOW_MULTI;
>  		} else if (is_prefix(argv[i], "override")) {
>  			attach_flags |= BPF_F_ALLOW_OVERRIDE;
> +		} else if (is_prefix(argv[i], "preorder")) {
> +			attach_flags |= BPF_F_PREORDER;
>  		} else {
>  			p_err("unknown option: %s", argv[i]);
>  			goto exit_cgroup;


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35436378806

Re: [PATCH bpf-next v2 3/3] bpftool: Add support for BPF_F_PREORDER cgroup attach flag

[Quentin Monnet]

2026-09-19 18:44 UTC+0900 ~ Hui Su <sh_def@163.com>
> Commit 4b82b181a26c ("bpf: Allow pre-ordering for bpf cgroup progs")
> introduced BPF_F_PREORDER to request pre-order execution across the
> cgroup hierarchy. Furthermore, attachments legitimately use combinations
> such as BPF_F_ALLOW_MULTI | BPF_F_PREORDER or
> BPF_F_ALLOW_OVERRIDE | BPF_F_PREORDER.
> 
> With BPF_PROG_QUERY reporting the per-program BPF_F_PREORDER attribute,
> bpftool's exact-match formatter falls back to "unknown(40)" when
> BPF_F_PREORDER is present alone, or "unknown(41)" / "unknown(42)" when
> combined with BPF_F_ALLOW_OVERRIDE or BPF_F_ALLOW_MULTI. Additionally,
> do_attach() only accepts "multi" and "override", rejecting "preorder" with
> "unknown option".
> 
> Before:
>   $ bpftool cgroup show <cg>
>   1234  cgroup_inet_ingress  unknown(42)  test_prog
>   $ bpftool cgroup attach <cg> cgroup_inet_ingress id 5678 multi preorder
>   Error: unknown option: preorder
> 
> After:
>   $ bpftool cgroup show <cg>
>   1234  cgroup_inet_ingress  multi,preorder  test_prog
>   $ bpftool cgroup attach <cg> cgroup_inet_ingress id 5678 multi preorder
>   (attaches successfully)
> 
> Refactor the attach flags formatter into a bitmask formatter that outputs
> comma-separated flag names while preserving unrecognized bits as
> "unknown(...)". Accept "preorder" in do_attach(), update the cgroup
> documentation and synopsis to express valid flag combinations, and teach
> bash completion about them ("multi" or "override" optionally combined with
> "preorder").
> 
> Signed-off-by: Hui Su <sh_def@163.com>


Thank you, please find some comments inline below:


> ---
>  .../bpftool/Documentation/bpftool-cgroup.rst  | 25 ++++++---
>  tools/bpf/bpftool/bash-completion/bpftool     |  4 +-
>  tools/bpf/bpftool/cgroup.c                    | 55 +++++++++++++------
>  3 files changed, 56 insertions(+), 28 deletions(-)
> 
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
> index e8185596a759..f8408ed44d74 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
> @@ -45,7 +45,7 @@ CGROUP COMMANDS
>  |     **cgroup_unix_recvmsg** | **cgroup_sysctl** |
>  |     **cgroup_getsockopt** | **cgroup_setsockopt** |
>  |     **cgroup_inet_sock_release** }
> -| *ATTACH_FLAGS* := { **multi** | **override** }
> +| *ATTACH_FLAGS* := { **multi** [ **preorder** ] | **override** [ **preorder** ] | **preorder** }


This looks more complex than it should, I think this should work just as
well:

    *ATTACH_FLAGS* := { [ **multi** | **override** ] [ **preorder** ] }

(and same for HELP_SPEC_ATTACH_FLAGS in cgroup.c)


>  
>  DESCRIPTION
>  ===========
> @@ -75,20 +75,27 @@ bpftool cgroup attach *CGROUP* *ATTACH_TYPE* *PROG* [*ATTACH_FLAGS*]
>      Attach program *PROG* to the cgroup *CGROUP* with attach type *ATTACH_TYPE*
>      and optional *ATTACH_FLAGS*.
>  
> -    *ATTACH_FLAGS* can be one of: **override** if a sub-cgroup installs some
> +    *ATTACH_FLAGS* can include: **override** if a sub-cgroup installs some
>      bpf program, the program in this cgroup yields to sub-cgroup program;
>      **multi** if a sub-cgroup installs some bpf program, that cgroup program
> -    gets run in addition to the program in this cgroup.
> +    gets run in addition to the program in this cgroup;
> +    **preorder** requests that this program executes in ancestor-to-descendant
> +    order before non-preorder descendants-to-ancestors programs during evaluation
> +    across the cgroup hierarchy. Note that **preorder** alone does not enable
> +    multi-program attachment; specify **multi** together with **preorder** to
> +    attach multiple programs.
>  
> -    Only one program is allowed to be attached to a cgroup with no attach flags
> -    or the **override** flag. Attaching another program will release old
> -    program and attach the new one.
> +    Only one program is allowed to be attached to a cgroup unless the
> +    **multi** flag is specified. Without **multi**, attaching another program
> +    replaces the existing program, provided the **override** setting matches.
>  
>      Multiple programs are allowed to be attached to a cgroup with **multi**.
> -    They are executed in FIFO order (those that were attached first, run
> -    first).
> +    Programs marked with **preorder** are placed before non-preorder programs
> +    in the effective program array. Within each ordering class at the same
> +    cgroup level, attachment order is preserved.
>  
> -    Non-default *ATTACH_FLAGS* are supported by kernel version 4.14 and later.
> +    **multi** and **override** are supported by kernel version 4.14 and later.
> +    **preorder** was introduced upstream in Linux 6.15.
>  
>      *ATTACH_TYPE* can be one of:
>  
> diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
> index 75cbcb512eba..a51c68029e16 100644
> --- a/tools/bpf/bpftool/bash-completion/bpftool
> +++ b/tools/bpf/bpftool/bash-completion/bpftool
> @@ -1057,7 +1057,6 @@ _bpftool()
>                  attach|detach)
>                      local BPFTOOL_CGROUP_ATTACH_TYPES="$(bpftool feature list_builtins attach_types 2>/dev/null | \
>                          grep '^cgroup_')"
> -                    local ATTACH_FLAGS='multi override'
>                      # Check for $prev = $command first
>                      if [ $prev = $command ]; then
>                          _filedir
> @@ -1087,7 +1086,8 @@ _bpftool()
>                                  # "id|pinned|tag|name" (we already checked for
>                                  # that). This should only leave the case when
>                                  # we need attach flags for "attach" commamnd.
> -                                _bpftool_one_of_list "$ATTACH_FLAGS"
> +                                _bpftool_one_of_list 'multi override'
> +                                _bpftool_once_attr 'preorder'
>                              fi
>                              return 0
>                              ;;
> diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
> index ce69d1e5468e..6ea0492ea532 100644
> --- a/tools/bpf/bpftool/cgroup.c
> +++ b/tools/bpf/bpftool/cgroup.c
> @@ -56,7 +56,7 @@ static const int cgroup_attach_types[] = {
>  };
>  
>  #define HELP_SPEC_ATTACH_FLAGS						\
> -	"ATTACH_FLAGS := { multi | override }"
> +	"ATTACH_FLAGS := { multi [ preorder ] | override [ preorder ] | preorder }"
>  
>  #define HELP_SPEC_ATTACH_TYPES						\
>  	"       ATTACH_TYPE := { cgroup_inet_ingress | cgroup_inet_egress |\n" \
> @@ -269,6 +269,39 @@ static int show_effective_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
>  	return 0;
>  }
>  
> +static const char *format_attach_flags(__u32 attach_flags, char *buf, size_t sz)
> +{
> +	static const struct {
> +		__u32 flag;
> +		const char *name;
> +	} flags[] = {
> +		{ BPF_F_ALLOW_MULTI, "multi" },
> +		{ BPF_F_ALLOW_OVERRIDE, "override" },
> +		{ BPF_F_PREORDER, "preorder" },
> +	};
> +	size_t len = 0;
> +	size_t i;
> +	int n;
> +
> +	buf[0] = '\0';
> +	for (i = 0; i < ARRAY_SIZE(flags); i++) {
> +		if (attach_flags & flags[i].flag) {
> +			n = snprintf(buf + len, sz - len, "%s%s",
> +				     len ? "," : "", flags[i].name);
> +			if (n < 0 || (size_t)n >= sz - len)
> +				return buf;
> +			len += n;
> +			attach_flags &= ~flags[i].flag;
> +		}
> +	}


I'm fine with that for bpftool's plain output. For JSON, given that we
introduce a change here already (output will be "multi,preorder" when
BPF_F_PREORDER is set, instead of "multi" previously), we should maybe
take that chance to print an array instead? Like this:

    "attach_flags": [ "multi", "preorder" ]


> +
> +	if (attach_flags)
> +		snprintf(buf + len, sz - len, "%sunknown(%x)",
> +			 len ? "," : "", attach_flags);
> +
> +	return buf;
> +}
> +
>  static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
>  				   int level)
>  {
> @@ -276,7 +309,7 @@ static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
>  	__u32 prog_attach_flags[1024] = {0};
>  	const char *attach_flags_str;
>  	__u32 prog_ids[1024] = {0};
> -	char buf[32];
> +	char buf[64];
>  	__u32 iter;
>  	int ret;
>  
> @@ -296,21 +329,7 @@ static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
>  		__u32 attach_flags;
>  
>  		attach_flags = prog_attach_flags[iter] ?: p.attach_flags;
> -
> -		switch (attach_flags) {
> -		case BPF_F_ALLOW_MULTI:
> -			attach_flags_str = "multi";
> -			break;
> -		case BPF_F_ALLOW_OVERRIDE:
> -			attach_flags_str = "override";
> -			break;
> -		case 0:
> -			attach_flags_str = "";
> -			break;
> -		default:
> -			snprintf(buf, sizeof(buf), "unknown(%x)", attach_flags);
> -			attach_flags_str = buf;
> -		}
> +		attach_flags_str = format_attach_flags(attach_flags, buf, sizeof(buf));
>  
>  		show_bpf_prog(prog_ids[iter], type,
>  			      attach_flags_str, level);
> @@ -593,6 +612,8 @@ static int do_attach(int argc, char **argv)
>  			attach_flags |= BPF_F_ALLOW_MULTI;
>  		} else if (is_prefix(argv[i], "override")) {
>  			attach_flags |= BPF_F_ALLOW_OVERRIDE;
> +		} else if (is_prefix(argv[i], "preorder")) {
> +			attach_flags |= BPF_F_PREORDER;
>  		} else {
>  			p_err("unknown option: %s", argv[i]);
>  			goto exit_cgroup;