> diff --git a/tools/testing/selftests/bpf/bpftool_helpers.c
> b/tools/testing/selftests/bpf/bpftool_helpers.c
> index c49fdd90eb033..9380b24bbf52b 100644
> --- a/tools/testing/selftests/bpf/bpftool_helpers.c
> +++ b/tools/testing/selftests/bpf/bpftool_helpers.c
> @@ -11,7 +11,7 @@
>
> #define BPFTOOL_DEFAULT_PATH "tools/sbin/bpftool"
>
> -static int detect_bpftool_path(char *buffer, size_t size)
> +int detect_bpftool_path(char *buffer, size_t size)
> {
> char tmp[PATH_MAX];
> const char *env_path;
> diff --git a/tools/testing/selftests/bpf/bpftool_helpers.h
> b/tools/testing/selftests/bpf/bpftool_helpers.h
> index dec1ba201410f..17e3be8e70730 100644
> --- a/tools/testing/selftests/bpf/bpftool_helpers.h
> +++ b/tools/testing/selftests/bpf/bpftool_helpers.h
> @@ -7,5 +7,6 @@
>
> #define MAX_BPFTOOL_CMD_LEN (256)
>
> +int detect_bpftool_path(char *buffer, size_t size);
> int run_bpftool_command(char *args);
> int get_bpftool_command_output(char *args, char *output_buf, size_t
> output_max_len);
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpftool_ringbuf.c
> b/tools/testing/selftests/bpf/prog_tests/bpftool_ringbuf.c
> new file mode 100644
> index 0000000000000..e9724c55d1dc6
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/bpftool_ringbuf.c
[ ... ]
> +static bool emit_record(struct bpftool_ringbuf *skel, int record)
> +{
> + char packet[64] = {};
> +
> + LIBBPF_OPTS(bpf_test_run_opts, opts,
> + .data_in = packet,
> + .data_size_in = sizeof(packet),
> + );
> +
> + skel->bss->record = record;
> + return
> ASSERT_OK(bpf_prog_test_run_opts(bpf_program__fd(skel->progs.produce),
> + &opts), "produce record") &&
> + ASSERT_OK(skel->bss->output_err, "ringbuf output");
> +}
This isn't a bug, but since emit_record() also drives the
bpf_perf_event_output() path for record 3, would a buffer-neutral tag
like "record output" read better here than "ringbuf output"?
[ ... ]
> +static void test_consumer(const char *format, bool idle, int signo, bool
> pinned)
> +{
[ ... ]
> + if (!idle) {
> + /* Both prefilled records occupy 16 bytes including their
> headers. */
> + if (!consumed(position, 32))
> + goto out;
This isn't a bug, but would it read more clearly as something like "each
prefilled record occupies 16 bytes including its header", so the 32 below
follows directly from the comment?
[ ... ]
> +static void test_perf_consumer(void)
> +{
[ ... ]
> + if (!ASSERT_OK(bpftool_ringbuf__load(skel), "load") ||
> + !consumer_start(&child, bpf_map__fd(skel->maps.perfbuf), NULL,
> + NULL, NULL, false, false) ||
> !consumer_ready(&child) ||
> + !emit_record(skel, 3))
> + goto out;
> + /* One large record flushes the existing buffered perf output callback.
> */
> + pfd = (struct pollfd) { .fd = child.fd, .events = POLLIN };
> + if (!ASSERT_GT(poll(&pfd, 1, WAIT_STEPS * WAIT_US / 1000), 0,
> + "perf record output") ||
This isn't a bug, but could this comment spell out that the perf callback
does not fflush() and the payload is sized so its hex output overflows
stdio's pipe buffer, so the poll() below has something to see?
[ ... ]
> diff --git a/tools/testing/selftests/bpf/progs/bpftool_ringbuf.c
> b/tools/testing/selftests/bpf/progs/bpftool_ringbuf.c
> new file mode 100644
> index 0000000000000..bbbc93c30a833
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/bpftool_ringbuf.c
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <linux/bpf.h>
> +#include <bpf/bpf_helpers.h>
> +
> +struct {
> + __uint(type, BPF_MAP_TYPE_RINGBUF);
> +} ringbuf SEC(".maps");
> +
> +struct {
> + __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
> + __uint(key_size, sizeof(__u32));
> + __uint(value_size, sizeof(__u32));
> + __uint(max_entries, 1);
> +} perfbuf SEC(".maps");
This isn't a bug, but since produce() emits with BPF_F_CURRENT_CPU and
test_perf_consumer() already resizes perfbuf to libbpf_num_possible_cpus(),
would it read better to drop `__uint(max_entries, 1)` and let libbpf size
the perf event array itself, the way progs/test_perf_buffer.c and
progs/perfbuf_bench.c do?
[ ... ]
---
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/35575071830
