the new introduced prog_attach_flags are not compatible

[mrpre]

bpftool/src/cgroup.c

Lines 235 to 245 in 43b5daa

	__u32 iter;
	int ret;
	p.query_flags = query_flags;
	p.prog_cnt = ARRAY_SIZE(prog_ids);
	p.prog_ids = prog_ids;
	p.prog_attach_flags = prog_attach_flags;
	ret = bpf_prog_query_opts(cgroup_fd, type, &p);
	if (ret)
	return ret;

prog_attach_flags is the latest field in uapi but not exist in older kernel
https://github.com/torvalds/linux/blob/7d2a07b769330c34b4deabeed939325c77a7ec2f/include/uapi/linux/bpf.h#L1400-L1407
and in kernel it will ensure all fields after it's last field(prog_cnt) must be zero

/* helper macro to check that unused fields 'union bpf_attr' are zero */
#define CHECK_ATTR(CMD) \
	memchr_inv((void *) &attr->CMD##_LAST_FIELD + \
		   sizeof(attr->CMD##_LAST_FIELD), 0, \
		   sizeof(*attr) - \
		   offsetof(union bpf_attr, CMD##_LAST_FIELD) - \
		   sizeof(attr->CMD##_LAST_FIELD)) != NULL

#define BPF_PROG_QUERY_LAST_FIELD query.prog_cnt

static int bpf_prog_query(const union bpf_attr *attr,
			  union bpf_attr __user *uattr)
{
	if (!capable(CAP_NET_ADMIN))
		return -EPERM;
	if (CHECK_ATTR(BPF_PROG_QUERY))
		return -EINVAL;
         ...
}  

It seems the upstream kernel doesn't have the compatibility issue because libbpf/bpftool is as the part of it's source.

[qmonnet]

Thanks for the report! So what happens in that case? It breaks bpftool cgroup tree, is this correct?

Relevant upstream commits: kernel, bpftool (Linux 6.1). I suppose the fix will be to retry if we get -EINVAL at this step (assuming that's what you get from the syscall?).

[qmonnet]

No feedback and no other report in two years, I'm closing the issue.