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

[bot+bpf-ci]

> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 149672c76c49c..e7c7efa1baa75 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -1353,19 +1353,19 @@ static int __cgroup_bpf_query(struct cgroup *cgrp, const union bpf_attr *attr,
>  				id = prog->aux->id;
>  				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;

This changes BPF_PROG_QUERY to report a new flag value (BPF_F_PREORDER)
that was never reported before. Could this cause compatibility issues
with the stable backport?

Before this patch, prog_attach_flags[i] could only contain
BPF_F_ALLOW_OVERRIDE (0x1) and BPF_F_ALLOW_MULTI (0x2). After this patch,
it can additionally carry BPF_F_PREORDER (0x40), producing new values 0x40
and 0x42 where 0x00/0x02 appeared before.

Existing in-tree userspace does exact-match formatting on these values.
tools/bpf/bpftool/cgroup.c, show_attached_bpf_progs(), before commit
2af5b738880b2 (the third commit in this series):

    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;
    }

The series' third commit documents the fallout: bpftool displays
"unknown(40)" when BPF_F_PREORDER is present alone, or "unknown(42)" when
combined with BPF_F_ALLOW_MULTI.

Within this series that is resolved (bpftool is fixed in commit 3), but
the tagging creates an asymmetry: this commit carries Fixes: 4b82b181a26c
(v6.15) which drives stable selection, while neither the selftest nor the
bpftool commit carries a Fixes: tag or stable Cc.

A stable backport of this commit alone would land the new query output on
a stable tree whose bpftool still has the exact-match switch, turning
bpftool cgroup show output from "multi" into "unknown(42)" for pre-ordered
attachments. The same skew applies to any distro bpftool older than
commit 3.

Should the Fixes: tag be dropped, or should the bpftool commit also carry
the same Fixes: tag so the two are backported together?

Also, the commit message does not state that BPF_PROG_QUERY starts
returning a previously-unreported bit in prog_attach_flags[]. Could that
compatibility fact be stated explicitly for reviewers?

---

Alexei Starovoitov raised a concern about the Fixes tag and target tree.
Alexei noted that this is not a bug fix but a user-space API change, and
existing bpftool will display "unknown(42)" for programs with
BPF_F_PREORDER. The suggestion was to target bpf-next (not bpf) and drop
the Fixes tag to prevent backporting to stable kernels.

Should this series target bpf-next instead of bpf, and should the Fixes
tag be removed?


---
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/35376083935