the new introduced prog_attach_flags are not compatible

[mrpre]

https://github.com/libbpf/bpftool/blob/43b5daa16a4b8afd71bba491950b54219fc35988/src/cgroup.c#L235-L245 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?).