From: sashiko-bot@kernel.org
To: "Jay Wang" <wanjay@amazon.com>,
bpf@vger.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>
Cc: "Ihor Solodrai" <ihor.solodrai@linux.dev>,
"Alan Maguire" <almagui@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Yonghong Song" <yonghong.song@linux.dev>,
"Jiri Olsa" <jolsa@kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
linux-trace-kernel@vger.kernel.org,
"Nathan Chancellor" <nathan@kernel.org>,
"Nicolas Schier" <nsc@kernel.org>,
linux-kbuild@vger.kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
x86@kernel.org, "Hazem Mohamed Abuelfotoh" <abuehaze@amazon.com>,
"Bjoern Doebel" <doebel@amazon.de>,
"Martin Pohlack" <mpohlack@amazon.de>,
jay.wang.upstream@gmail.com
Subject: Re: [PATCH bpf-next 08/13] tracing: parse the vmlinux BTF when BTF-typed output is enabled
Date: Sat, 31 Oct 2026 13:37:08 +0000 [thread overview]
Message-ID: <sashiko-outbox-191980@kernel.org> (raw)
In-Reply-To: <20261031130959.23472-9-wanjay@amazon.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] tracing: missing trace_btf_prepare() in irqsoff and wakeup tracers
- [Medium] tracing: missing trace_btf_prepare() for persistent buffers and latency tracers
--
commit b7e170f2972f546cc8806104f942bd820ff8ecbb
Author: Ihor Solodrai <ihor.solodrai@linux.dev>
tracing: parse the vmlinux BTF when BTF-typed output is enabled
This commit prepares the vmlinux BTF when BTF-typed function or function_graph
tracer output is enabled or when reading an event's btf_ids file, and changes
print_function_args() and btf_trim_retval() to peek at the vmlinux BTF rather
than parsing it on demand while holding trace read locks.
> diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
> index a5ad76175d10d..cdb926c9d4e21 100644
> --- a/kernel/trace/trace_output.c
> +++ b/kernel/trace/trace_output.c
> @@ -739,6 +739,9 @@ void print_function_args(struct trace_seq *s, unsigned long *args,
> if (lookup_symbol_name(func, name))
> goto out;
>
> + /* see trace_btf_prepare() */
> + if (IS_ERR_OR_NULL(bpf_peek_btf_vmlinux()))
> + goto out;
[Severity: Medium]
Can this cause recorded function arguments to be omitted (printed as empty
parentheses) for latency tracers and persistent boot ring buffers when
CONFIG_DEBUG_INFO_BTF_LAZY is enabled and nothing else has triggered vmlinux
BTF parsing yet?
First, when CONFIG_FUNCTION_TRACE_ARGS is enabled, the irqsoff, preemptoff,
preemptirqsoff, wakeup, wakeup_rt, and wakeup_dl latency tracers record
function arguments via fregs into TRACE_FN entries since commit 76fe0337c219
("ftrace: Add arguments to function tracer"):
kernel/trace/trace_irqsoff.c:irqsoff_tracer_call() {
...
trace_function(tr, ip, parent_ip, trace_ctx, fregs);
}
kernel/trace/trace_sched_wakeup.c:wakeup_tracer_call() {
...
local_irq_save(flags);
trace_function(tr, ip, parent_ip, trace_ctx, fregs);
local_irq_restore(flags);
}
When reading trace or trace_pipe in default (non-graph) mode,
irqsoff_print_line() and wakeup_print_line() return TRACE_TYPE_UNHANDLED,
which dispatches TRACE_FN entries through trace_fn_trace() ->
print_fn_trace() -> print_function_args():
kernel/trace/trace_output.c:trace_fn_trace() {
...
args_size = iter->ent_size - offsetof(struct ftrace_entry, args);
if (args_size >= FTRACE_REGS_MAX_ARGS * sizeof(long))
args = field->args;
else
args = NULL;
print_fn_trace(s, field->ip, field->parent_ip, args, iter->tr, flags);
}
However, neither __irqsoff_tracer_init() / register_irqsoff_function() nor
__wakeup_tracer_init() / register_wakeup_function() calls trace_btf_prepare().
Second, when a persistent trace_array instance (TRACE_ARRAY_FL_LAST_BOOT) is
set up across boots via trace_instance= on the command line (using reserve_mem
or backup= in enable_instances()), allocate_trace_buffer() and
setup_trace_scratch() preserve the ring buffer events and address deltas from
the previous boot while the instance starts in the new boot with nop_trace and
default tracer flags. Selecting a tracer in the new boot via
tracing_set_tracer() calls update_last_data(tr), which resets the ring buffer
and clears the previous boot data (and backup= instances are marked
TRACE_ARRAY_FL_RDONLY):
kernel/trace/trace.c:tracing_set_tracer() {
...
guard(mutex)(&trace_types_lock);
update_last_data(tr);
...
}
When reading trace or trace_pipe from that persistent instance to inspect the
previous boot's TRACE_FN or TRACE_GRAPH_ENT entries, print_trace_fmt()
dispatches them to trace_fn_trace() -> print_fn_trace() ->
print_function_args() or print_graph_function_event() ->
print_graph_entry_leaf() / print_graph_entry_nested() ->
print_function_args() without trace_btf_prepare() having been called in the
current boot:
kernel/trace/trace_output.c:print_fn_trace() {
...
ip = trace_adjust_address(tr, ip);
parent_ip = trace_adjust_address(tr, parent_ip);
seq_print_ip_sym(s, ip, flags);
if (args)
print_function_args(s, args, ip);
...
}
Should trace_btf_prepare() also be called when initializing the irqsoff and
wakeup tracers and when setting up a persistent last-boot trace buffer?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261031130959.23472-1-wanjay@amazon.com?part=8
next prev parent reply other threads:[~2026-10-31 13:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-31 13:09 [PATCH bpf-next 00/13] bpf: keep the vmlinux BTF compressed until first use (CONFIG_DEBUG_INFO_BTF_LAZY) to save ~6 MB memory Jay Wang
2026-10-31 13:09 ` [PATCH bpf-next 01/13] bpf: match program context types by name without vmlinux BTF Jay Wang
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 02/13] bpf: fetch the vmlinux BTF where kernel types enter a program Jay Wang
2026-10-31 13:42 ` sashiko-bot
2026-10-31 13:55 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 03/13] bpf: check CAP_SYS_ADMIN before looking up bpffs delegation names Jay Wang
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 17:03 ` Alexei Starovoitov
2026-10-31 13:09 ` [PATCH bpf-next 04/13] bpf: move bpf_get_btf_vmlinux() to btf.c Jay Wang
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 05/13] bpf: let btf_parse_module() adopt the caller's copy of the module BTF Jay Wang
2026-10-31 13:09 ` [PATCH bpf-next 06/13] bpf: look up the struct_ops common value type in the given BTF Jay Wang
2026-10-31 13:09 ` [PATCH bpf-next 07/13] bpf: parse the vmlinux BTF before taking cand_cache_mutex Jay Wang
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 08/13] tracing: parse the vmlinux BTF when BTF-typed output is enabled Jay Wang
2026-10-31 13:37 ` sashiko-bot [this message]
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 09/13] bpf: keep the vmlinux BTF zstd-compressed in the kernel image Jay Wang
2026-10-31 13:33 ` sashiko-bot
2026-10-31 13:55 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 10/13] bpf: defer kfunc and struct_ops registrations until first BTF use Jay Wang
2026-10-31 13:38 ` sashiko-bot
2026-10-31 13:55 ` bot+bpf-ci
2026-10-31 17:07 ` Alexei Starovoitov
2026-10-31 13:09 ` [PATCH bpf-next 11/13] bpf: keep module BTF until the vmlinux BTF is parsed Jay Wang
2026-10-31 13:37 ` sashiko-bot
2026-10-31 13:55 ` bot+bpf-ci
2026-10-31 17:10 ` Alexei Starovoitov
2026-10-31 13:09 ` [PATCH bpf-next 12/13] selftests/bpf: keep ksyms and linked_vars working without __start_BTF Jay Wang
2026-10-31 13:09 ` [PATCH bpf-next 13/13] Documentation/bpf: describe CONFIG_DEBUG_INFO_BTF_LAZY Jay Wang
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=sashiko-outbox-191980@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=abuehaze@amazon.com \
--cc=almagui@kernel.org \
--cc=andrii@kernel.org \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=doebel@amazon.de \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=jay.wang.upstream@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mathieu.desnoyers@efficios.com \
--cc=memxor@gmail.com \
--cc=mhiramat@kernel.org \
--cc=mpohlack@amazon.de \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=rostedt@goodmis.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wanjay@amazon.com \
--cc=x86@kernel.org \
--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