From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>, <bpf@vger.kernel.org>
Cc: "Andrii Nakryiko" <andrii@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Emil Tsalapatis" <emil@etsalapatis.com>,
"Tejun Heo" <tj@kernel.org>, <kkd@meta.com>,
<kernel-team@meta.com>
Subject: Re: [PATCH bpf-next v2 4/5] bpftool: Read program streams through file descriptors
Date: Thu, 24 Sep 2026 21:12:22 +0000 [thread overview]
Message-ID: <DLNUU0R42VG1.3P1RX5FK30FZU@gmail.com> (raw)
In-Reply-To: <20260924162641.1922423-5-memxor@gmail.com>
On Thu, Sep 24, 2026 at 06:26 PM Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
> Use bpf_prog_stream_open() in its default blocking mode when following a
> program stream. This lets bpftool wait for later output instead of exiting
> as soon as it drains the currently buffered bytes. Flush each chunk as it
> arrives so redirected output is not held in stdio buffers while the next
> read blocks.
So the same 'bpftool prog tracelog stderr PROG' prints what is buffered
and exits on old kernels and doesn't return on new ones while the prog
is loaded. Scripts that dump the stream will hang.
Probably should be opt-in?
[...]
> + while (!stream_stop) {
> + ret = read(fd, buf, sizeof(buf));
A signal that arrives after the stream_stop check and before read()
blocks only sets the flag. read() then sleeps until the next print or
the next signal.
exit_tracelog() calls exit(0) from the handler.
can we do the same here ?
Then stream_stop and save/restore of old[] are not needed.
next prev parent reply other threads:[~2026-09-24 21:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 16:26 [PATCH bpf-next v2 0/5] File descriptor interface for BPF streams Kumar Kartikeya Dwivedi
2026-09-24 16:26 ` [PATCH bpf-next v2 1/5] bpf: Skip zero-length stream writes Kumar Kartikeya Dwivedi
2026-09-24 16:26 ` [PATCH bpf-next v2 2/5] bpf: Add file descriptor interface for program streams Kumar Kartikeya Dwivedi
2026-09-24 21:11 ` Alexei Starovoitov
2026-09-24 16:26 ` [PATCH bpf-next v2 3/5] libbpf: Add bpf_prog_stream_open() Kumar Kartikeya Dwivedi
2026-09-24 16:26 ` [PATCH bpf-next v2 4/5] bpftool: Read program streams through file descriptors Kumar Kartikeya Dwivedi
2026-09-24 21:12 ` Alexei Starovoitov [this message]
2026-09-24 16:26 ` [PATCH bpf-next v2 5/5] selftests/bpf: Test program stream " Kumar Kartikeya Dwivedi
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=DLNUU0R42VG1.3P1RX5FK30FZU@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=kernel-team@meta.com \
--cc=kkd@meta.com \
--cc=memxor@gmail.com \
--cc=tj@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.