From: bot+bpf-ci@kernel.org
To: alexis.lothore@bootlin.com,andrii@kernel.org,eddyz87@gmail.com,ihor.solodrai@linux.dev,ast@kernel.org,daniel@iogearbox.net,memxor@gmail.com,martin.lau@linux.dev,song@kernel.org,yonghong.song@linux.dev,jolsa@kernel.org,emil@etsalapatis.com,shuah@kernel.org
Cc: ebpf@linuxfoundation.org,bastien.curutchet@bootlin.com,thomas.petazzoni@bootlin.com,linux-kernel@vger.kernel.org,bpf@vger.kernel.org,linux-kselftest@vger.kernel.org,alexis.lothore@bootlin.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 1/2] selftests/bpf: add helpers to manipulate ftrace
Date: Fri, 30 Oct 2026 19:34:58 +0000 (UTC) [thread overview]
Message-ID: <09475f69602098aa106af66960f75de688d53ca24efdf8dcdc6f91c0d2a59c6e@mail.kernel.org> (raw)
In-Reply-To: <20261030-ftrace_in_test_progs-v1-1-aa50c5dd1ccc@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 3178 bytes --]
> selftests/bpf: add helpers to manipulate ftrace
TL;DR: Restoring ftrace filters in trace_helpers.c may abort on a saved line
over 126 bytes (128-byte buffer), leaving the filter empty, so all functions
get traced and global ftrace state isn't restored.
> diff --git a/tools/testing/selftests/bpf/trace_helpers.c b/tools/testing/selftests/bpf/trace_helpers.c
> index 6d7a4b8c4ab8..1f26a057a810 100644
> --- a/tools/testing/selftests/bpf/trace_helpers.c
> +++ b/tools/testing/selftests/bpf/trace_helpers.c
[ ... ]
> +#define CHUNK_SIZE 128
[ ... ]
> +static const char *tracefs_next_line(const char *content, char *buf, size_t size,
> + int *err)
> +{
> + const char *end;
> + size_t len;
> +
> + *err = 0;
> + while (*content) {
> + end = strchrnul(content, '\n');
> + len = end - content;
> + content = *end ? end + 1 : end;
> +
> + if (!len || end[-len] == '#')
> + continue;
> +
> + if (len + 2 > size) {
> + *err = -ENAMETOOLONG;
> + return NULL;
> + }
> + memcpy(buf, end - len, len);
> + buf[len++] = '\n';
> + buf[len] = '\0';
> + return content;
> + }
> +
> + return NULL;
> +}
> +
> +static int tracefs_restore_file(const struct tracefs_ctl_entry *entry)
> +{
> + char buf[CHUNK_SIZE];
> + const char *content = entry->old;
> + int err = 0;
> +
> + if (!content)
> + return 0;
> +
> + if (entry->kind == TRACEFS_CTL_FILTER) {
> + err = tracefs_write_file(entry->path, "");
> + if (err)
> + return err;
> + }
> +
> + while ((content = tracefs_next_line(content, buf, sizeof(buf), &err))) {
> + err = tracefs_write_file(entry->path, buf);
> + if (err)
> + return err;
> + }
> +
> + return err;
> +}
Can a saved line longer than 126 bytes abort the restore here?
tracefs_restore_file() splits the saved content into a buffer sized by the
read chunk constant:
char buf[CHUNK_SIZE]; /* CHUNK_SIZE is 128 */
and tracefs_next_line() fails the whole restore with -ENAMETOOLONG when
len + 2 > size. The kernel can print much longer entries than that.
print_rec() emits the full symbol (KSYM_NAME_LEN is 512) plus the
" [module]" suffix, so mangled Rust symbols or long C names with a module
suffix can exceed 126 bytes.
For TRACEFS_CTL_FILTER entries the file has already been emptied by
tracefs_write_file(entry->path, "") before the long line is reached:
if (entry->kind == TRACEFS_CTL_FILTER) {
err = tracefs_write_file(entry->path, "");
...
}
while ((content = tracefs_next_line(content, buf, sizeof(buf), &err))) {
so the restore stops part-way, every entry after the long line is lost, and
if none were restored yet the filter is left empty. For set_ftrace_filter
an empty filter means all functions are traced, which is the opposite of
the original restriction, and the global ftrace state is not restored.
Should the line buffer be sized to the actual line length (or should the
content be written straight from the saved string) instead of being tied to
CHUNK_SIZE?
---
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/41113297251
next prev parent reply other threads:[~2026-10-30 19:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 18:50 [PATCH bpf-next 0/2] selftests/bpf: port test_ftrace.sh into test_progs Alexis Lothoré (eBPF Foundation)
2026-10-30 18:50 ` [PATCH bpf-next 1/2] selftests/bpf: add helpers to manipulate ftrace Alexis Lothoré (eBPF Foundation)
2026-10-30 19:34 ` bot+bpf-ci [this message]
2026-10-30 18:50 ` [PATCH bpf-next 2/2] selftests/bpf: port test_ftrace.sh to test_progs Alexis Lothoré (eBPF Foundation)
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=09475f69602098aa106af66960f75de688d53ca24efdf8dcdc6f91c0d2a59c6e@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=alexis.lothore@bootlin.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bastien.curutchet@bootlin.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=ebpf@linuxfoundation.org \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mason@kernel.org \
--cc=memxor@gmail.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=yonghong.song@linux.dev \
/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
all inboxes | Powered by JetHome®