From: Yuan Chen <chenyuan_fl@163.com>
To: bpf@vger.kernel.org
Cc: Quentin Monnet <qmo@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Yuan Chen <chenyuan_fl@163.com>
Subject: [PATCH bpf-next v6 0/2] bpftool: fix batch file handling issues
Date: Mon, 24 Aug 2026 17:26:55 +0800 [thread overview]
Message-ID: <20260824092657.1789956-1-chenyuan_fl@163.com> (raw)
In-Reply-To: <20260810142224.2907373-1-chenyuan_fl@163.com>
This series fixes two remaining issues in bpftool's batch file handling
(the double-close fix from v5 has been applied upstream and is no
longer part of this series):
1. do_batch() reports a spurious read failure because a stale errno
left by a previously executed command is checked after the read
loop instead of the outcome of the last fgets() call.
2. a line longer than the batch buffer that contains a '#' within the
buffered prefix bypasses the line length check: the comment
stripping truncates the buffer before the length is checked, so the
unread remainder of the line is parsed and executed as a separate
command on the next loop iteration. Continuation lines are affected
the same way, bypassing the "command is too long" check.
Many thanks to Andrii Nakryiko for the review: patch 1 now clears errno
before each fgets() call instead of tracking the too-long-line case
with an explicit flag, and patch 2 moves the line-length checks before
the comment stripping instead of detecting truncated reads with
memchr()/feof().
Changes in v6:
- drop the double-close patch, which has been applied upstream; the
series is now two patches
- "fix spurious batch file read error": clear errno before each
fgets() call, and drop the explicit line_too_long flag and the
ferror() check (reviewer feedback)
- "Fix bypass of the batch line length check by comments": move the
line-length checks before the comment stripping, dropping the
memchr()/feof() truncation detection (reviewer feedback)
Yuan Chen (2):
bpftool: fix spurious batch file read error
bpftool: Fix bypass of the batch line length check by comments
tools/bpf/bpftool/main.c | 30 ++++++++++++------------------
1 file changed, 12 insertions(+), 18 deletions(-)
next prev parent reply other threads:[~2026-08-24 9:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 14:22 [PATCH bpf-next v5 0/3] bpftool: fix batch file handling issues chenyuan_fl
2026-08-10 14:22 ` [PATCH bpf-next v5 1/3] bpftool: fix double close in map dump chenyuan_fl
2026-08-10 14:22 ` [PATCH bpf-next v5 2/3] bpftool: fix spurious batch file read error chenyuan_fl
2026-08-13 21:56 ` Andrii Nakryiko
2026-08-10 14:22 ` [PATCH bpf-next v5 3/3] bpftool: Fix bypass of the batch line length check by comments chenyuan_fl
2026-08-10 14:44 ` sashiko-bot
2026-08-13 22:00 ` Andrii Nakryiko
2026-08-24 9:26 ` Yuan Chen [this message]
2026-08-24 9:26 ` [PATCH bpf-next v6 1/2] bpftool: fix spurious batch file read error Yuan Chen
2026-08-24 10:02 ` bot+bpf-ci
2026-08-28 0:10 ` patchwork-bot+netdevbpf
2026-08-24 9:26 ` [PATCH bpf-next v6 2/2] bpftool: Fix bypass of the batch line length check by comments Yuan Chen
2026-08-28 0:10 ` patchwork-bot+netdevbpf
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=20260824092657.1789956-1-chenyuan_fl@163.com \
--to=chenyuan_fl@163.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=memxor@gmail.com \
--cc=qmo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox