All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Monnet <qmo@kernel.org>
To: Tianyi Chen <diannaaav@gmail.com>, bpf@vger.kernel.org
Cc: andrii@kernel.org, eddyz87@gmail.com, ihor.solodrai@linux.dev,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 2/2] selftests/bpf: Cover bpftool ring buffer event_pipe
Date: Fri, 18 Sep 2026 13:18:39 +0100	[thread overview]
Message-ID: <5bded51f-d0f9-41ae-92ad-e1ce008a101e@kernel.org> (raw)
In-Reply-To: <20260911025114.190899-3-diannaaav@gmail.com>

2026-09-11 10:51 UTC+0800 ~ Tianyi Chen <diannaaav@gmail.com>
> From: Tianyi Chen <hi@tychen.cc>
> 
> Produce known ring buffer records and check complete plain, JSON and
> pretty JSON output. Exercise ID and pinned map selection, SIGINT and
> SIGTERM shutdown, empty streams and invalid map types or selectors.
> 
> Also produce a perf event sample and check its existing header and raw
> payload output. Use a payload whose size plus the raw sample length
> field is aligned to eight bytes so the expected bytes exclude implicit
> perf padding.
> 
> Assisted-by: LLM
> Signed-off-by: Tianyi Chen <hi@tychen.cc>
> ---
>  .../bpf/prog_tests/bpftool_ringbuf.c          | 425 ++++++++++++++++++
>  .../selftests/bpf/progs/bpftool_ringbuf.c     |  47 ++
>  2 files changed, 472 insertions(+)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/bpftool_ringbuf.c
>  create mode 100644 tools/testing/selftests/bpf/progs/bpftool_ringbuf.c
> 
> 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 000000000000..1a4ae88c05a0
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/bpftool_ringbuf.c
> @@ -0,0 +1,425 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <ctype.h>
> +#include <fcntl.h>
> +#include <poll.h>
> +#include <signal.h>
> +#include <sys/mman.h>
> +#include <sys/wait.h>
> +#include <test_progs.h>
> +#include "bpftool_ringbuf.skel.h"
> +
> +#define WAIT_STEPS 500
> +#define WAIT_US 10000
> +
> +struct consumer {
> +	pid_t pid;
> +	int fd;
> +};
> +
> +static const char *bpftool_path(void)
> +{
> +	const char *path = getenv("BPFTOOL");
> +
> +	if (path)
> +		return access(path, X_OK) ? NULL : path;
> +	if (!access("./tools/sbin/bpftool", X_OK))
> +		return "./tools/sbin/bpftool";
> +	if (!access("../tools/sbin/bpftool", X_OK))
> +		return "../tools/sbin/bpftool";
> +	return NULL;
> +}


As bpf-ci's review says, please look into reusing the existing helpers
if possible.


> +
> +static void consumer_cleanup(struct consumer *child)
> +{
> +	if (child->pid > 0) {
> +		kill(child->pid, SIGKILL);
> +		while (waitpid(child->pid, NULL, 0) < 0 && errno == EINTR)
> +			;
> +		child->pid = -1;
> +	}
> +	if (child->fd >= 0) {
> +		close(child->fd);
> +		child->fd = -1;
> +	}
> +}
> +
> +static bool consumer_start(struct consumer *child, int map_fd, const char *format,
> +			   const char *pin_path, const char *option,
> +			   bool pair, bool capture_errors)
> +{
> +	struct bpf_map_info info = {};
> +	__u32 len = sizeof(info);
> +	const char *path = bpftool_path();
> +	char *argv[12], id[16];
> +	int out[2], ready[2], n = 0, err, err_fd;
> +	struct pollfd pfd;
> +
> +	if (!ASSERT_OK_PTR(path, "bpftool path (set BPFTOOL to override)") ||
> +	    !ASSERT_OK(bpf_map_get_info_by_fd(map_fd, &info, &len), "map info"))
> +		return false;
> +	snprintf(id, sizeof(id), "%u", info.id);
> +	argv[n++] = (char *)path;
> +	if (format)
> +		argv[n++] = (char *)format;
> +	argv[n++] = "map";
> +	argv[n++] = "event_pipe";
> +	argv[n++] = pin_path ? "pinned" : "id";
> +	argv[n++] = pin_path ? (char *)pin_path : id;
> +	if (option) {
> +		argv[n++] = (char *)option;
> +		argv[n++] = "0";
> +		if (pair) {
> +			argv[n++] = "index";
> +			argv[n++] = "0";
> +		}
> +	}
> +	argv[n] = NULL;
> +	if (!ASSERT_OK(pipe2(out, O_CLOEXEC), "output pipe"))
> +		return false;
> +	if (!ASSERT_OK(pipe2(ready, O_CLOEXEC), "exec pipe")) {
> +		close(out[0]);
> +		close(out[1]);
> +		return false;
> +	}
> +	child->pid = fork();
> +	if (!child->pid) {
> +		close(out[0]);
> +		close(ready[0]);
> +		err_fd = capture_errors ? out[1] : open("/dev/null", O_WRONLY);
> +		if (dup2(out[1], STDOUT_FILENO) < 0 ||
> +		    dup2(err_fd, STDERR_FILENO) < 0)
> +			goto exec_fail;
> +		if (!capture_errors)
> +			close(err_fd);
> +		close(out[1]);
> +		execv(path, argv);
> +exec_fail:
> +		err = errno;
> +		write(ready[1], &err, sizeof(err));


I think that ignoring the return value from write() can produce a
compiler warning (-Wunused-result).

[...]

Looks OK otherwise, thank you

  parent reply	other threads:[~2026-09-18 12:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11  2:51 [PATCH bpf-next v3 0/2] bpftool: Consume ring buffer maps with event_pipe Tianyi Chen
2026-09-11  2:51 ` [PATCH bpf-next v3 1/2] bpftool: Read " Tianyi Chen
2026-09-18 12:18   ` Quentin Monnet
2026-09-19 11:48     ` Tianyi Chen
2026-09-11  2:51 ` [PATCH bpf-next v3 2/2] selftests/bpf: Cover bpftool ring buffer event_pipe Tianyi Chen
2026-09-11  3:57   ` bot+bpf-ci
2026-09-18 12:18   ` Quentin Monnet [this message]
     [not found] ` <e7211adda619bf43e17dbaf59ffec76ca2442726a5e22485cd783ed9a5e9c655@mail.kernel.org>
2026-09-11  5:12   ` [PATCH bpf-next v3 0/2] bpftool: Consume ring buffer maps with event_pipe Tianyi Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5bded51f-d0f9-41ae-92ad-e1ce008a101e@kernel.org \
    --to=qmo@kernel.org \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=diannaaav@gmail.com \
    --cc=eddyz87@gmail.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=linux-kselftest@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.