Re: [PATCH bpf-next v14 2/8] libbpf: Add support for extended BPF syscall
From: bot+bpf-ci@kernel.org
Date: 2026-05-12 16:23:16
Also in:
bpf, linux-kselftest, lkml
quoted hunk ↗ jump to hunk
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c index 5846de364209..9d8740761b7a 100644 --- a/tools/lib/bpf/bpf.c +++ b/tools/lib/bpf/bpf.c
[ ... ]
+int probe_sys_bpf_ext(void)
+{
+ const size_t attr_sz = offsetofend(union bpf_attr, prog_token_fd);
+ union bpf_attr attr;
+ int fd;
+
+ memset(&attr, 0, attr_sz);
+ fd = syscall(__NR_bpf, BPF_PROG_LOAD | BPF_COMMON_ATTRS, &attr, attr_sz, NULL,
+ sizeof(struct bpf_common_attr));
+ if (fd >= 0) {
+ close(fd);
+ return -EINVAL;^^^^^^ Should probe_sys_bpf_ext() return 1 instead of -EINVAL when fd >= 0? The probe function detects kernel support for extended BPF syscall attributes by calling the BPF syscall with the BPF_COMMON_ATTRS flag and a NULL pointer for common attributes. The expected outcomes are: - New kernel with support: errno=EFAULT (can't copy from NULL) -> return 1 - Old kernel without support: errno!=EFAULT (invalid command) -> return 0 If the syscall succeeds (fd >= 0), that definitively proves the kernel accepts the extended syscall format and supports BPF_COMMON_ATTRS. The function should return 1 (supported) rather than -EINVAL (error). Returning -EINVAL causes feat_supported() in features.c to print a warning "Detection of kernel BPF syscall common attributes support support failed: Invalid argument" and mark the feature as MISSING, incorrectly reporting that the kernel doesn't support the feature when the successful syscall proves it does.
+ } + return errno == EFAULT ? 1 : 0; +}
[ ... ] --- 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/25745661172