* [PATCH v5 1/3] ftrace: Build trace_btf.c when CONFIG_DEBUG_INFO_BTF is enabled
2026-09-01 13:46 [PATCH v5 0/3] Use BTF to trim return values Donglin Peng
@ 2026-09-01 13:46 ` Donglin Peng
2026-09-02 14:58 ` Masami Hiramatsu
2026-09-01 13:46 ` [PATCH v5 2/3] fgraph: Enhance funcgraph-retval with BTF-based type-aware output Donglin Peng
` (2 subsequent siblings)
3 siblings, 1 reply; 15+ messages in thread
From: Donglin Peng @ 2026-09-01 13:46 UTC (permalink / raw)
To: rostedt
Cc: mhiramat, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin, Xiaoqin Zhang
From: pengdonglin <pengdonglin@xiaomi.com>
The trace_btf.c file provides BTF helper functions used by the ftrace
subsystem. Make the compilation of trace_btf.c solely depend on
CONFIG_DEBUG_INFO_BTF, allowing features like funcgraph-retval to also
utilize these helpers.
Additionally, the redundant dependency on CONFIG_PROBE_EVENTS_BTF_ARGS
is removed, as CONFIG_DEBUG_INFO_BTF already depends on
CONFIG_BPF_SYSCALL.
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Xiaoqin Zhang <zhangxiaoqin@xiaomi.com>
Signed-off-by: pengdonglin <pengdonglin@xiaomi.com>
---
kernel/trace/Kconfig | 2 +-
kernel/trace/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 0ab5916575a9..d8faeb659cfc 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -770,7 +770,7 @@ config FPROBE_EVENTS
config PROBE_EVENTS_BTF_ARGS
depends on HAVE_FUNCTION_ARG_ACCESS_API
depends on FPROBE_EVENTS || KPROBE_EVENTS
- depends on DEBUG_INFO_BTF && BPF_SYSCALL
+ depends on DEBUG_INFO_BTF
bool "Support BTF function arguments for probe events"
default y
help
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index f934ff586bd4..28b08f31e7e5 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -119,7 +119,7 @@ obj-$(CONFIG_KGDB_KDB) += trace_kdb.o
endif
obj-$(CONFIG_DYNAMIC_EVENTS) += trace_dynevent.o
obj-$(CONFIG_PROBE_EVENTS) += trace_probe.o
-obj-$(CONFIG_PROBE_EVENTS_BTF_ARGS) += trace_btf.o
+obj-$(CONFIG_DEBUG_INFO_BTF) += trace_btf.o
obj-$(CONFIG_UPROBE_EVENTS) += trace_uprobe.o
obj-$(CONFIG_BOOTTIME_TRACING) += trace_boot.o
obj-$(CONFIG_FTRACE_RECORD_RECURSION) += trace_recursion_record.o
--
2.34.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH v5 1/3] ftrace: Build trace_btf.c when CONFIG_DEBUG_INFO_BTF is enabled
2026-09-01 13:46 ` [PATCH v5 1/3] ftrace: Build trace_btf.c when CONFIG_DEBUG_INFO_BTF is enabled Donglin Peng
@ 2026-09-02 14:58 ` Masami Hiramatsu
0 siblings, 0 replies; 15+ messages in thread
From: Masami Hiramatsu @ 2026-09-02 14:58 UTC (permalink / raw)
To: Donglin Peng
Cc: rostedt, mhiramat, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin, Xiaoqin Zhang
On Tue, 1 Sep 2026 21:46:02 +0800
Donglin Peng <dolinux.peng@gmail.com> wrote:
> From: pengdonglin <pengdonglin@xiaomi.com>
>
> The trace_btf.c file provides BTF helper functions used by the ftrace
> subsystem. Make the compilation of trace_btf.c solely depend on
> CONFIG_DEBUG_INFO_BTF, allowing features like funcgraph-retval to also
> utilize these helpers.
>
> Additionally, the redundant dependency on CONFIG_PROBE_EVENTS_BTF_ARGS
> is removed, as CONFIG_DEBUG_INFO_BTF already depends on
> CONFIG_BPF_SYSCALL.
OK, nowadays BPF requires BTF. This looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks,
>
> Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
> Cc: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Xiaoqin Zhang <zhangxiaoqin@xiaomi.com>
> Signed-off-by: pengdonglin <pengdonglin@xiaomi.com>
> ---
> kernel/trace/Kconfig | 2 +-
> kernel/trace/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index 0ab5916575a9..d8faeb659cfc 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -770,7 +770,7 @@ config FPROBE_EVENTS
> config PROBE_EVENTS_BTF_ARGS
> depends on HAVE_FUNCTION_ARG_ACCESS_API
> depends on FPROBE_EVENTS || KPROBE_EVENTS
> - depends on DEBUG_INFO_BTF && BPF_SYSCALL
> + depends on DEBUG_INFO_BTF
> bool "Support BTF function arguments for probe events"
> default y
> help
> diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
> index f934ff586bd4..28b08f31e7e5 100644
> --- a/kernel/trace/Makefile
> +++ b/kernel/trace/Makefile
> @@ -119,7 +119,7 @@ obj-$(CONFIG_KGDB_KDB) += trace_kdb.o
> endif
> obj-$(CONFIG_DYNAMIC_EVENTS) += trace_dynevent.o
> obj-$(CONFIG_PROBE_EVENTS) += trace_probe.o
> -obj-$(CONFIG_PROBE_EVENTS_BTF_ARGS) += trace_btf.o
> +obj-$(CONFIG_DEBUG_INFO_BTF) += trace_btf.o
> obj-$(CONFIG_UPROBE_EVENTS) += trace_uprobe.o
> obj-$(CONFIG_BOOTTIME_TRACING) += trace_boot.o
> obj-$(CONFIG_FTRACE_RECORD_RECURSION) += trace_recursion_record.o
> --
> 2.34.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v5 2/3] fgraph: Enhance funcgraph-retval with BTF-based type-aware output
2026-09-01 13:46 [PATCH v5 0/3] Use BTF to trim return values Donglin Peng
2026-09-01 13:46 ` [PATCH v5 1/3] ftrace: Build trace_btf.c when CONFIG_DEBUG_INFO_BTF is enabled Donglin Peng
@ 2026-09-01 13:46 ` Donglin Peng
2026-09-01 14:10 ` sashiko-bot
2026-09-01 13:46 ` [PATCH v5 3/3] tracing: Update funcgraph-retval documentation Donglin Peng
2026-09-01 17:57 ` [PATCH v5 0/3] Use BTF to trim return values Steven Rostedt
3 siblings, 1 reply; 15+ messages in thread
From: Donglin Peng @ 2026-09-01 13:46 UTC (permalink / raw)
To: rostedt
Cc: mhiramat, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin, Xiaoqin Zhang
From: pengdonglin <pengdonglin@xiaomi.com>
The current funcgraph-retval implementation suffers from two accuracy
issues:
1. Void-returning functions still print a return value, creating
misleading noise in the trace output.
2. For functions returning narrower types (e.g., char, short), the
displayed value can be incorrect because high bits of the register
may contain undefined data.
This patch addresses both problems by leveraging BTF to obtain the exact
return type of each traced kernel function. The key changes are:
1. Void function filtering: Functions with void return type no longer
display any return value in the trace output, eliminating unnecessary
clutter.
2. Type-aware value formatting: The return value is now properly truncated
to match the actual width of the return type before being displayed.
Additionally, the value is formatted according to its type for better
human readability.
Here is an output comparison:
Before:
# perf ftrace -G vfs_read --graph-opts retval
...
1) | touch_atime() {
1) | atime_needs_update() {
1) 0.069 us | make_vfsuid(); /* ret=0x0 */
1) 0.067 us | make_vfsgid(); /* ret=0x0 */
1) | current_time() {
1) 0.197 us | ktime_get_coarse_real_ts64_mg(); /* ret=0x187f886aec3ed6f5 */
1) 0.352 us | } /* current_time ret=0x69380753 */
1) 0.792 us | } /* atime_needs_update ret=0x0 */
1) 0.937 us | } /* touch_atime ret=0x0 */
After:
# perf ftrace -G vfs_read --graph-opts retval
...
2) | touch_atime() {
2) | atime_needs_update() {
2) 0.070 us | make_vfsuid(); /* ret=0x0 */
2) 0.070 us | make_vfsgid(); /* ret=0x0 */
2) | current_time() {
2) 0.162 us | ktime_get_coarse_real_ts64_mg();
2) 0.312 us | } /* current_time ret=0x69380649(trunc) */
2) 0.753 us | } /* atime_needs_update ret=false */
2) 0.899 us | } /* touch_atime */
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Xiaoqin Zhang <zhangxiaoqin@xiaomi.com>
Signed-off-by: pengdonglin <pengdonglin@xiaomi.com>
---
kernel/trace/trace_btf.c | 68 ++++++++++++++++++++++++++++
kernel/trace/trace_btf.h | 16 +++++++
kernel/trace/trace_functions_graph.c | 50 ++++++++++++++------
3 files changed, 121 insertions(+), 13 deletions(-)
diff --git a/kernel/trace/trace_btf.c b/kernel/trace/trace_btf.c
index 00172f301f25..38825f566235 100644
--- a/kernel/trace/trace_btf.c
+++ b/kernel/trace/trace_btf.c
@@ -2,6 +2,7 @@
#include <linux/btf.h>
#include <linux/kernel.h>
#include <linux/slab.h>
+#include <linux/kallsyms.h>
#include "trace_btf.h"
@@ -120,3 +121,70 @@ const struct btf_member *btf_find_struct_member(struct btf *btf,
return member;
}
+#ifdef CONFIG_DEBUG_INFO_BTF
+void btf_trim_retval(unsigned long func, unsigned long *retval, bool *print_retval,
+ int *fmt)
+{
+ const struct btf_type *t;
+ char name[KSYM_NAME_LEN];
+ struct btf *btf;
+ u32 v, msb;
+ int kind;
+
+ if (lookup_symbol_name(func, name))
+ return;
+
+ t = btf_find_func_proto(name, &btf);
+ if (IS_ERR_OR_NULL(t))
+ return;
+
+ t = btf_type_skip_modifiers(btf, t->type, NULL);
+ kind = t ? BTF_INFO_KIND(t->info) : BTF_KIND_UNKN;
+ switch (kind) {
+ case BTF_KIND_UNKN:
+ *print_retval = false;
+ break;
+ case BTF_KIND_STRUCT:
+ case BTF_KIND_UNION:
+ case BTF_KIND_ENUM:
+ case BTF_KIND_ENUM64:
+ if (kind == BTF_KIND_STRUCT || kind == BTF_KIND_UNION)
+ *fmt = RETVAL_FMT_HEX;
+ else
+ *fmt = RETVAL_FMT_DEC;
+
+ if (t->size > sizeof(unsigned long)) {
+ *fmt |= RETVAL_FMT_TRUNC;
+ } else {
+ msb = BITS_PER_BYTE * t->size - 1;
+ *retval &= GENMASK(msb, 0);
+ }
+ break;
+ case BTF_KIND_INT:
+ v = *(u32 *)(t + 1);
+ if (BTF_INT_ENCODING(v) == BTF_INT_BOOL) {
+ *fmt = RETVAL_FMT_BOOL;
+ msb = 0;
+ } else {
+ if (BTF_INT_ENCODING(v) == BTF_INT_SIGNED)
+ *fmt = RETVAL_FMT_DEC;
+ else
+ *fmt = RETVAL_FMT_HEX;
+
+ if (t->size > sizeof(unsigned long)) {
+ *fmt |= RETVAL_FMT_TRUNC;
+ msb = BITS_PER_LONG - 1;
+ } else {
+ msb = BTF_INT_BITS(v) - 1;
+ }
+ }
+ *retval &= GENMASK(msb, 0);
+ break;
+ default:
+ *fmt = RETVAL_FMT_HEX;
+ break;
+ }
+
+ btf_put(btf);
+}
+#endif
diff --git a/kernel/trace/trace_btf.h b/kernel/trace/trace_btf.h
index 4bc44bc261e6..3675d99c22eb 100644
--- a/kernel/trace/trace_btf.h
+++ b/kernel/trace/trace_btf.h
@@ -1,6 +1,13 @@
/* SPDX-License-Identifier: GPL-2.0 */
#include <linux/btf.h>
+enum {
+ RETVAL_FMT_HEX = BIT(0),
+ RETVAL_FMT_DEC = BIT(1),
+ RETVAL_FMT_BOOL = BIT(2),
+ RETVAL_FMT_TRUNC = BIT(3),
+};
+
const struct btf_type *btf_find_func_proto(const char *func_name,
struct btf **btf_p);
const struct btf_param *btf_get_func_param(const struct btf_type *func_proto,
@@ -9,3 +16,12 @@ const struct btf_member *btf_find_struct_member(struct btf *btf,
const struct btf_type *type,
const char *member_name,
u32 *anon_offset);
+#ifdef CONFIG_DEBUG_INFO_BTF
+void btf_trim_retval(unsigned long func, unsigned long *retval, bool *print_retval,
+ int *fmt);
+#else
+static inline void btf_trim_retval(unsigned long func, unsigned long *retval,
+ bool *print_retval, int *fmt)
+{
+}
+#endif
diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
index ff7cb1a76b95..89a64982df2c 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -15,6 +15,7 @@
#include "trace.h"
#include "trace_output.h"
+#include "trace_btf.h"
/* When set, irq functions might be ignored */
static int ftrace_graph_skip_irqs;
@@ -877,7 +878,7 @@ static void print_graph_retval(struct trace_seq *s, struct ftrace_graph_ent_entr
unsigned long retval = 0;
bool print_retaddr = false;
bool print_retval = false;
- bool hex_format = !!(opt_flags & TRACE_GRAPH_PRINT_RETVAL_HEX);
+ int retval_fmt = 0;
#ifdef CONFIG_FUNCTION_GRAPH_RETVAL
retval = graph_ret->retval;
@@ -888,17 +889,35 @@ static void print_graph_retval(struct trace_seq *s, struct ftrace_graph_ent_entr
print_retaddr = !!(opt_flags & TRACE_GRAPH_PRINT_RETADDR);
#endif
- if (print_retval && retval && !hex_format) {
- /* Check if the return value matches the negative format */
- if (IS_ENABLED(CONFIG_64BIT) && (retval & BIT(31)) &&
- (((u64)retval) >> 32) == 0) {
- err_code = sign_extend64(retval, 31);
- } else {
- err_code = retval;
+ if (print_retval) {
+ int fmt = RETVAL_FMT_HEX;
+
+ btf_trim_retval((unsigned long)func, &retval, &print_retval, &fmt);
+ if (print_retval) {
+ if (opt_flags & TRACE_GRAPH_PRINT_RETVAL_HEX)
+ retval_fmt = RETVAL_FMT_HEX;
+
+ if (retval && retval_fmt != RETVAL_FMT_HEX) {
+ /* Check if the return value matches the negative format */
+ if (IS_ENABLED(CONFIG_64BIT) && (retval & BIT(31)) &&
+ (((u64)retval) >> 32) == 0) {
+ err_code = sign_extend64(retval, 31);
+ } else {
+ err_code = retval;
+ }
+
+ if (!IS_ERR_VALUE(err_code))
+ err_code = 0;
+ }
+
+ if (retval_fmt == RETVAL_FMT_HEX) {
+ retval_fmt |= (fmt & RETVAL_FMT_TRUNC);
+ } else {
+ if (err_code && fmt & RETVAL_FMT_HEX)
+ fmt = (fmt & ~RETVAL_FMT_HEX) | RETVAL_FMT_DEC;
+ retval_fmt = fmt;
+ }
}
-
- if (!IS_ERR_VALUE(err_code))
- err_code = 0;
}
if (entry) {
@@ -925,10 +944,15 @@ static void print_graph_retval(struct trace_seq *s, struct ftrace_graph_ent_entr
trace_flags, false);
if (print_retval) {
- if (hex_format || (err_code == 0))
+ if (retval_fmt & RETVAL_FMT_HEX)
trace_seq_printf(s, " ret=0x%lx", retval);
+ else if (retval_fmt & RETVAL_FMT_BOOL)
+ trace_seq_printf(s, " ret=%s", retval ? "true" : "false");
else
- trace_seq_printf(s, " ret=%ld", err_code);
+ trace_seq_printf(s, " ret=%ld", err_code ?: retval);
+
+ if (retval_fmt & RETVAL_FMT_TRUNC)
+ trace_seq_printf(s, "(trunc)");
}
if (!entry || print_retval || print_retaddr)
--
2.34.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH v5 2/3] fgraph: Enhance funcgraph-retval with BTF-based type-aware output
2026-09-01 13:46 ` [PATCH v5 2/3] fgraph: Enhance funcgraph-retval with BTF-based type-aware output Donglin Peng
@ 2026-09-01 14:10 ` sashiko-bot
0 siblings, 0 replies; 15+ messages in thread
From: sashiko-bot @ 2026-09-01 14:10 UTC (permalink / raw)
To: Donglin Peng; +Cc: linux-trace-kernel
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Calling bpf_find_btf_id() during trace formatting introduces a spinlock acquisition into atomic/NMI contexts, leading to deadlocks and kernel panics during oops reporting.
- [High] bpf_find_btf_id() performs global name-based BTF lookups per trace event, causing severe O(N) performance degradation, lock contention, and incorrect typing for module/static functions.
- [Medium] Functions returning empty structs (size 0) cause an integer underflow in the bitmask calculation, triggering undefined behavior in the GENMASK macro.
- [Medium] btf_trim_retval incorrectly zero-extends signed narrow types (e.g., s8, s16), breaking the formatting of negative values and error codes.
--
commit b33d384f150276d1e47f02dbd04205841c0951e8
Author: pengdonglin <pengdonglin@xiaomi.com>
fgraph: Enhance funcgraph-retval with BTF-based type-aware output
The current funcgraph-retval implementation suffers from two accuracy issues:
void-returning functions print return values, and narrower types can contain
undefined data in high bits. This patch leverages BTF to obtain the exact
return type of each traced function, eliminating clutter for void functions
and properly truncating/formatting return values.
> diff --git a/kernel/trace/trace_btf.c b/kernel/trace/trace_btf.c
> index 00172f301f25a..38825f5662351 100644
> --- a/kernel/trace/trace_btf.c
> +++ b/kernel/trace/trace_btf.c
[ ... ]
> @@ -120,3 +121,70 @@ const struct btf_member *btf_find_struct_member(struct btf *btf,
> return member;
> }
>
> +#ifdef CONFIG_DEBUG_INFO_BTF
> +void btf_trim_retval(unsigned long func, unsigned long *retval, bool *print_retval,
> + int *fmt)
> +{
[ ... ]
> + switch (kind) {
[ ... ]
> + case BTF_KIND_STRUCT:
> + case BTF_KIND_UNION:
> + case BTF_KIND_ENUM:
> + case BTF_KIND_ENUM64:
> + if (kind == BTF_KIND_STRUCT || kind == BTF_KIND_UNION)
> + *fmt = RETVAL_FMT_HEX;
> + else
> + *fmt = RETVAL_FMT_DEC;
> +
> + if (t->size > sizeof(unsigned long)) {
> + *fmt |= RETVAL_FMT_TRUNC;
> + } else {
> + msb = BITS_PER_BYTE * t->size - 1;
> + *retval &= GENMASK(msb, 0);
> + }
[Severity: Medium]
Can this calculation underflow msb?
If the traced function returns an empty struct (e.g., struct {} in GNU C),
t->size is 0. The calculation BITS_PER_BYTE * 0 - 1 will underflow to
4294967295.
Passing this huge value to GENMASK(msb, 0) invokes C undefined behavior due to
out-of-bounds bitwise shifts.
> + break;
> + case BTF_KIND_INT:
> + v = *(u32 *)(t + 1);
> + if (BTF_INT_ENCODING(v) == BTF_INT_BOOL) {
> + *fmt = RETVAL_FMT_BOOL;
> + msb = 0;
> + } else {
> + if (BTF_INT_ENCODING(v) == BTF_INT_SIGNED)
> + *fmt = RETVAL_FMT_DEC;
> + else
> + *fmt = RETVAL_FMT_HEX;
> +
> + if (t->size > sizeof(unsigned long)) {
> + *fmt |= RETVAL_FMT_TRUNC;
> + msb = BITS_PER_LONG - 1;
> + } else {
> + msb = BTF_INT_BITS(v) - 1;
> + }
> + }
> + *retval &= GENMASK(msb, 0);
[Severity: Medium]
Will this unconditional masking destroy the sign bit extension for signed
narrow integers like s8 or s16?
The masking clears the upper sign-extension bits. Since the legacy
IS_ERR_VALUE() check in print_graph_retval() only inspects bit 31, which will
be 0 for these narrow types, negative values (like error codes) will be
incorrectly printed as positive integers.
> + break;
> + default:
> + *fmt = RETVAL_FMT_HEX;
> + break;
> + }
> +
> + btf_put(btf);
> +}
> +#endif
> diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
> index ff7cb1a76b953..89a64982df2cc 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
[ ... ]
> @@ -888,17 +889,35 @@ static void print_graph_retval(struct trace_seq *s, struct ftrace_graph_ent_entr
> print_retaddr = !!(opt_flags & TRACE_GRAPH_PRINT_RETADDR);
> #endif
>
> - if (print_retval && retval && !hex_format) {
> - /* Check if the return value matches the negative format */
> - if (IS_ENABLED(CONFIG_64BIT) && (retval & BIT(31)) &&
> - (((u64)retval) >> 32) == 0) {
> - err_code = sign_extend64(retval, 31);
> - } else {
> - err_code = retval;
> - }
> + if (print_retval) {
> + int fmt = RETVAL_FMT_HEX;
>
> - if (!IS_ERR_VALUE(err_code))
> - err_code = 0;
> + btf_trim_retval((unsigned long)func, &retval, &print_retval, &fmt);
[Severity: High]
Is it safe to call bpf_find_btf_id() from this trace formatting path,
considering it might run in atomic/NMI contexts?
This trace formatting function can run in NMI context via ftrace_dump_one(),
which executes with local IRQs disabled:
kernel/trace/trace.c:ftrace_dump_one()
...
local_irq_save(flags);
...
btf_trim_retval() eventually calls bpf_find_btf_id(), which unconditionally
acquires btf_idr_lock using spin_lock_bh(). Taking a bottom-half lock in hard
IRQ/NMI context triggers WARN_ON_ONCE(irqs_disabled()) and causes deadlocks
if the lock is already held.
[Severity: High]
Could this global name-based lookup cause severe O(N) performance degradation
during trace reads?
Trace formatting executes for every function return event. btf_trim_retval()
uses lookup_symbol_name() to convert the IP to a string, and then globally
searches BTF by name.
For module functions, this requires acquiring the global btf_idr_lock and
iterating over all modules per event, completely stalling trace formatting and
contending with BPF operations. Additionally, it causes incorrect typing for
static functions with common names, as it will just return the first match in
vmlinux.
> + if (print_retval) {
> + if (opt_flags & TRACE_GRAPH_PRINT_RETVAL_HEX)
> + retval_fmt = RETVAL_FMT_HEX;
> +
> + if (retval && retval_fmt != RETVAL_FMT_HEX) {
> + /* Check if the return value matches the negative format */
> + if (IS_ENABLED(CONFIG_64BIT) && (retval & BIT(31)) &&
> + (((u64)retval) >> 32) == 0) {
> + err_code = sign_extend64(retval, 31);
> + } else {
> + err_code = retval;
> + }
> +
> + if (!IS_ERR_VALUE(err_code))
> + err_code = 0;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260901134604.4052265-1-dolinux.peng@gmail.com?part=2
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v5 3/3] tracing: Update funcgraph-retval documentation
2026-09-01 13:46 [PATCH v5 0/3] Use BTF to trim return values Donglin Peng
2026-09-01 13:46 ` [PATCH v5 1/3] ftrace: Build trace_btf.c when CONFIG_DEBUG_INFO_BTF is enabled Donglin Peng
2026-09-01 13:46 ` [PATCH v5 2/3] fgraph: Enhance funcgraph-retval with BTF-based type-aware output Donglin Peng
@ 2026-09-01 13:46 ` Donglin Peng
2026-09-01 14:20 ` sashiko-bot
2026-09-01 17:57 ` [PATCH v5 0/3] Use BTF to trim return values Steven Rostedt
3 siblings, 1 reply; 15+ messages in thread
From: Donglin Peng @ 2026-09-01 13:46 UTC (permalink / raw)
To: rostedt
Cc: mhiramat, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin, Xiaoqin Zhang
From: pengdonglin <pengdonglin@xiaomi.com>
The existing documentation for funcgraph-retval is outdated and partially
incorrect, as it describes limitations that have now been resolved.
Recent changes (e.g., using BTF to obtain function return types) have
addressed key issues:
1. Return values are now printed only for non-void functions.
2. Values are trimmed to the correct width of the return type, avoiding
garbage data from high bits.
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Xiaoqin Zhang <zhangxiaoqin@xiaomi.com>
Signed-off-by: pengdonglin <pengdonglin@xiaomi.com>
---
Documentation/trace/ftrace.rst | 88 +++++++++++++++++++---------------
1 file changed, 50 insertions(+), 38 deletions(-)
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 7261f25f8b4b..696bfbede590 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -1483,6 +1483,10 @@ Options for function_graph tracer:
printed in hexadecimal format. By default, this option
is off.
+ funcgraph-retaddr
+ When set, the return address will always be printed.
+ By default, this option is off.
+
sleep-time
When running function graph tracer, to include
the time a task schedules out in its function.
@@ -2829,7 +2833,7 @@ It is default disabled.
0) 2.861 us | } /* putname() */
The return value of each traced function can be displayed after
-an equal sign "=". When encountering system call failures, it
+an equal sign "ret=". When encountering system call failures, it
can be very helpful to quickly locate the function that first
returns an error code.
@@ -2839,16 +2843,16 @@ returns an error code.
Example with funcgraph-retval::
1) | cgroup_migrate() {
- 1) 0.651 us | cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
+ 1) 0.651 us | cgroup_migrate_add_task(); /* ret=0xffff93fcfd346c00 */
1) | cgroup_migrate_execute() {
1) | cpu_cgroup_can_attach() {
1) | cgroup_taskset_first() {
- 1) 0.732 us | cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
- 1) 1.232 us | } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
- 1) 0.380 us | sched_rt_can_attach(); /* = 0x0 */
- 1) 2.335 us | } /* cpu_cgroup_can_attach = -22 */
- 1) 4.369 us | } /* cgroup_migrate_execute = -22 */
- 1) 7.143 us | } /* cgroup_migrate = -22 */
+ 1) 0.732 us | cgroup_taskset_next(); /* ret=0xffff93fc8fb20000 */
+ 1) 1.232 us | } /* cgroup_taskset_first ret=0xffff93fc8fb20000 */
+ 1) 0.380 us | sched_rt_can_attach(); /* ret=0x0 */
+ 1) 2.335 us | } /* cpu_cgroup_can_attach ret=-22 */
+ 1) 4.369 us | } /* cgroup_migrate_execute ret=-22 */
+ 1) 7.143 us | } /* cgroup_migrate ret=-22 */
The above example shows that the function cpu_cgroup_can_attach
returned the error code -22 firstly, then we can read the code
@@ -2865,37 +2869,41 @@ printed in hexadecimal format.
Example with funcgraph-retval-hex::
1) | cgroup_migrate() {
- 1) 0.651 us | cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
+ 1) 0.651 us | cgroup_migrate_add_task(); /* ret=0xffff93fcfd346c00 */
1) | cgroup_migrate_execute() {
1) | cpu_cgroup_can_attach() {
1) | cgroup_taskset_first() {
- 1) 0.732 us | cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
- 1) 1.232 us | } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
- 1) 0.380 us | sched_rt_can_attach(); /* = 0x0 */
- 1) 2.335 us | } /* cpu_cgroup_can_attach = 0xffffffea */
- 1) 4.369 us | } /* cgroup_migrate_execute = 0xffffffea */
- 1) 7.143 us | } /* cgroup_migrate = 0xffffffea */
-
-At present, there are some limitations when using the funcgraph-retval
-option, and these limitations will be eliminated in the future:
-
-- Even if the function return type is void, a return value will still
- be printed, and you can just ignore it.
-
-- Even if return values are stored in multiple registers, only the
- value contained in the first register will be recorded and printed.
- To illustrate, in the x86 architecture, eax and edx are used to store
- a 64-bit return value, with the lower 32 bits saved in eax and the
- upper 32 bits saved in edx. However, only the value stored in eax
- will be recorded and printed.
-
-- In certain procedure call standards, such as arm64's AAPCS64, when a
- type is smaller than a GPR, it is the responsibility of the consumer
- to perform the narrowing, and the upper bits may contain UNKNOWN values.
- Therefore, it is advisable to check the code for such cases. For instance,
- when using a u8 in a 64-bit GPR, bits [63:8] may contain arbitrary values,
- especially when larger types are truncated, whether explicitly or implicitly.
- Here are some specific cases to illustrate this point:
+ 1) 0.732 us | cgroup_taskset_next(); /* ret=0xffff93fc8fb20000 */
+ 1) 1.232 us | } /* cgroup_taskset_first ret=0xffff93fc8fb20000 */
+ 1) 0.380 us | sched_rt_can_attach(); /* ret=0x0 */
+ 1) 2.335 us | } /* cpu_cgroup_can_attach ret=0xffffffea */
+ 1) 4.369 us | } /* cgroup_migrate_execute ret=0xffffffea */
+ 1) 7.143 us | } /* cgroup_migrate ret=0xffffffea */
+
+Note that there are some limitations when using the funcgraph-retval
+option:
+
+- If CONFIG_DEBUG_INFO_BTF is disabled (n), a return value is printed even for
+ functions with a void return type. When CONFIG_DEBUG_INFO_BTF is enabled (y),
+ the return value is printed only for non-void functions.
+
+- If a return value occupies multiple registers, only the value in the first
+ register is recorded and printed. For example, on the x86 architecture, a
+ 64-bit return value is stored across eax (lower 32 bits) and edx (upper 32 bits),
+ but only the contents of eax are captured. If CONFIG_DEBUG_INFO_BTF is enabled,
+ the suffix "(trunc)" is appended to the printed value to indicate that the
+ output may be truncated because high-order register contents are omitted.
+
+- Under certain procedure-call standards (e.g., arm64's AAPCS64), when the return
+ type is smaller than a general-purpose register (GPR), the caller is responsible
+ for narrowing the value; the upper bits of the register may contain undefined data.
+ For instance, when a u8 is returned in 64-bit GPR, bits [63:8] can hold arbitrary
+ values, especially when larger types are truncated (explicitly or implicitly). It
+ is therefore advisable to inspect the code in such cases. If CONFIG_DEBUG_INFO_BTF
+ is enabled (y), the return value is automatically trimmed to the width of the return
+ type.
+
+ The following examples illustrate the behavior:
**Case One**:
@@ -2914,7 +2922,9 @@ option, and these limitations will be eliminated in the future:
RET
If you pass 0x123456789abcdef to this function and want to narrow it,
- it may be recorded as 0x123456789abcdef instead of 0xef.
+ it may be recorded as 0x123456789abcdef instead of 0xef. When
+ CONFIG_DEBUG_INFO_BTF is enabled, the value will be correctly truncated
+ to 0xef based on the size constraints of the u8 type.
**Case Two**:
@@ -2939,7 +2949,9 @@ option, and these limitations will be eliminated in the future:
RET
When passing 0x2_0000_0000 to it, the return value may be recorded as
- 0x2_0000_0000 instead of 0.
+ 0x2_0000_0000 instead of 0. When CONFIG_DEBUG_INFO_BTF is enabled, the
+ value will be correctly truncated to 0 based on the size constraints of
+ the int type.
You can put some comments on specific functions by using
trace_printk() For example, if you want to put a comment inside
--
2.34.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH v5 3/3] tracing: Update funcgraph-retval documentation
2026-09-01 13:46 ` [PATCH v5 3/3] tracing: Update funcgraph-retval documentation Donglin Peng
@ 2026-09-01 14:20 ` sashiko-bot
0 siblings, 0 replies; 15+ messages in thread
From: sashiko-bot @ 2026-09-01 14:20 UTC (permalink / raw)
To: Donglin Peng; +Cc: linux-trace-kernel
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Undefined behavior in `btf_trim_retval()` when evaluating `GENMASK()` for zero-sized types like empty structs.
- [Medium] Zero-extension of signed return values breaks display formatting for negative integers.
--
commit 9a068f6032f17c7055ec2012793c0a9a00b1e9a0
Author: pengdonglin <pengdonglin@xiaomi.com>
tracing: Update funcgraph-retval documentation
The existing documentation for funcgraph-retval is outdated and partially
incorrect, as it describes limitations that have now been resolved. Recent
changes (e.g., using BTF to obtain function return types) have addressed
key issues.
> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> index 7261f25f8b4ba..696bfbede5905 100644
> --- a/Documentation/trace/ftrace.rst
> +++ b/Documentation/trace/ftrace.rst
[ ... ]
> +- Under certain procedure-call standards (e.g., arm64's AAPCS64), when the return
> + type is smaller than a general-purpose register (GPR), the caller is responsible
> + for narrowing the value; the upper bits of the register may contain undefined data.
> + For instance, when a u8 is returned in 64-bit GPR, bits [63:8] can hold arbitrary
> + values, especially when larger types are truncated (explicitly or implicitly). It
> + is therefore advisable to inspect the code in such cases. If CONFIG_DEBUG_INFO_BTF
> + is enabled (y), the return value is automatically trimmed to the width of the return
> + type.
[Severity: High]
Does the trimming logic in btf_trim_retval() handle empty structs correctly?
Looking at btf_trim_retval() in kernel/trace/trace_btf.c:
msb = BITS_PER_BYTE * t->size - 1;
*retval &= GENMASK(msb, 0);
If a function returns a zero-sized type (like an empty struct), t->size is 0.
This causes msb to underflow to 0xFFFFFFFF, which means GENMASK(0xFFFFFFFF, 0)
attempts a shift by 64. Can this trigger undefined behavior and potentially a
UBSAN panic if CONFIG_UBSAN_SHIFT is enabled?
[Severity: Medium]
Also, does this zero-extension break display formatting for negative integers?
When a function returns a negative value, btf_trim_retval() zeroes out the
upper bits. Later in kernel/trace/trace_functions_graph.c:print_graph_retval():
if (!IS_ERR_VALUE(err_code))
err_code = 0;
// ...
trace_seq_printf(s, " ret=%ld", err_code ?: retval);
For non-error negative values (like -5000) or small signed types (like s8),
IS_ERR_VALUE() evaluates to false, resetting err_code to 0. The code then
falls back to printing the zero-extended retval as a positive number using
%ld. Won't this cause these negative returns to be printed as large positive
numbers instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260901134604.4052265-1-dolinux.peng@gmail.com?part=3
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v5 0/3] Use BTF to trim return values
2026-09-01 13:46 [PATCH v5 0/3] Use BTF to trim return values Donglin Peng
` (2 preceding siblings ...)
2026-09-01 13:46 ` [PATCH v5 3/3] tracing: Update funcgraph-retval documentation Donglin Peng
@ 2026-09-01 17:57 ` Steven Rostedt
2026-09-02 3:25 ` Peng Donglin
3 siblings, 1 reply; 15+ messages in thread
From: Steven Rostedt @ 2026-09-01 17:57 UTC (permalink / raw)
To: Donglin Peng
Cc: mhiramat, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin
On Tue, 1 Sep 2026 21:46:01 +0800
Donglin Peng <dolinux.peng@gmail.com> wrote:
> From: pengdonglin <pengdonglin@xiaomi.com>
>
> The funcgraph-retval option currently records one machine-word return
> value without considering the function's declared return type. As a
> result, void-returning functions can produce meaningless output, and
> return values narrower than a general-purpose register can include
> undefined high bits.
>
> This series uses kernel BTF to identify the return type of traced
> functions and to improve funcgraph-retval output:
>
> - Do not print a return value for functions with a void return type.
> - Trim integer, enum, struct, and union values to the available return
> value width when the BTF type provides suitable size information.
> - Format integer, enum, and boolean values according to their BTF
> encoding.
> - Mark values as "(trunc)" when the return type is wider than the
> value captured by the function graph tracer.
Hmm, I really don't like the "(trunc)" If it's the real return type, then
it should just print what the real size is. No need to state it was truncated.
-- Steve
>
> Here is an output comparison:
>
> Before:
> # perf ftrace -G vfs_read --graph-opts retval
> ...
> 1) | touch_atime() {
> 1) | atime_needs_update() {
> 1) 0.069 us | make_vfsuid(); /* ret=0x0 */
> 1) 0.067 us | make_vfsgid(); /* ret=0x0 */
> 1) | current_time() {
> 1) 0.197 us | ktime_get_coarse_real_ts64_mg(); /* ret=0x187f886aec3ed6f5 */
> 1) 0.352 us | } /* current_time ret=0x69380753 */
> 1) 0.792 us | } /* atime_needs_update ret=0x0 */
> 1) 0.937 us | } /* touch_atime ret=0x0 */
>
> After:
> # perf ftrace -G vfs_read --graph-opts retval
> ...
> 2) | touch_atime() {
> 2) | atime_needs_update() {
> 2) 0.070 us | make_vfsuid(); /* ret=0x0 */
> 2) 0.070 us | make_vfsgid(); /* ret=0x0 */
> 2) | current_time() {
> 2) 0.162 us | ktime_get_coarse_real_ts64_mg();
> 2) 0.312 us | } /* current_time ret=0x69380649(trunc) */
> 2) 0.753 us | } /* atime_needs_update ret=false */
> 2) 0.899 us | } /* touch_atime */
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH v5 0/3] Use BTF to trim return values
2026-09-01 17:57 ` [PATCH v5 0/3] Use BTF to trim return values Steven Rostedt
@ 2026-09-02 3:25 ` Peng Donglin
2026-09-02 14:55 ` Masami Hiramatsu
0 siblings, 1 reply; 15+ messages in thread
From: Peng Donglin @ 2026-09-02 3:25 UTC (permalink / raw)
To: Steven Rostedt
Cc: mhiramat, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin
On 9/2/26 01:57, Steven Rostedt wrote:
> On Tue, 1 Sep 2026 21:46:01 +0800
> Donglin Peng <dolinux.peng@gmail.com> wrote:
>
>> From: pengdonglin <pengdonglin@xiaomi.com>
>>
>> The funcgraph-retval option currently records one machine-word return
>> value without considering the function's declared return type. As a
>> result, void-returning functions can produce meaningless output, and
>> return values narrower than a general-purpose register can include
>> undefined high bits.
>>
>> This series uses kernel BTF to identify the return type of traced
>> functions and to improve funcgraph-retval output:
>>
>> - Do not print a return value for functions with a void return type.
>> - Trim integer, enum, struct, and union values to the available return
>> value width when the BTF type provides suitable size information.
>> - Format integer, enum, and boolean values according to their BTF
>> encoding.
>> - Mark values as "(trunc)" when the return type is wider than the
>> value captured by the function graph tracer.
>
> Hmm, I really don't like the "(trunc)" If it's the real return type, then
> it should just print what the real size is. No need to state it was truncated.
Thanks, I agree. We can remove the "(trunc)" suffix and print the actual
type information instead, for example:
ret=0x5[struct:0x10]
This would indicate that the return type is a struct with a size of 0x10
bytes.
Would this be acceptable?
>
> -- Steve
>
>>
>> Here is an output comparison:
>>
>> Before:
>> # perf ftrace -G vfs_read --graph-opts retval
>> ...
>> 1) | touch_atime() {
>> 1) | atime_needs_update() {
>> 1) 0.069 us | make_vfsuid(); /* ret=0x0 */
>> 1) 0.067 us | make_vfsgid(); /* ret=0x0 */
>> 1) | current_time() {
>> 1) 0.197 us | ktime_get_coarse_real_ts64_mg(); /* ret=0x187f886aec3ed6f5 */
>> 1) 0.352 us | } /* current_time ret=0x69380753 */
>> 1) 0.792 us | } /* atime_needs_update ret=0x0 */
>> 1) 0.937 us | } /* touch_atime ret=0x0 */
>>
>> After:
>> # perf ftrace -G vfs_read --graph-opts retval
>> ...
>> 2) | touch_atime() {
>> 2) | atime_needs_update() {
>> 2) 0.070 us | make_vfsuid(); /* ret=0x0 */
>> 2) 0.070 us | make_vfsgid(); /* ret=0x0 */
>> 2) | current_time() {
>> 2) 0.162 us | ktime_get_coarse_real_ts64_mg();
>> 2) 0.312 us | } /* current_time ret=0x69380649(trunc) */
>> 2) 0.753 us | } /* atime_needs_update ret=false */
>> 2) 0.899 us | } /* touch_atime */
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH v5 0/3] Use BTF to trim return values
2026-09-02 3:25 ` Peng Donglin
@ 2026-09-02 14:55 ` Masami Hiramatsu
2026-09-03 16:17 ` Donglin Peng
2026-09-03 16:36 ` Steven Rostedt
0 siblings, 2 replies; 15+ messages in thread
From: Masami Hiramatsu @ 2026-09-02 14:55 UTC (permalink / raw)
To: Peng Donglin
Cc: Steven Rostedt, mhiramat, dolinux.peng, linux-trace-kernel,
linux-kernel, pengdonglin
On Wed, 2 Sep 2026 11:25:29 +0800
Peng Donglin <dolinux.peng@gmail.com> wrote:
> >> - Do not print a return value for functions with a void return type.
> >> - Trim integer, enum, struct, and union values to the available return
> >> value width when the BTF type provides suitable size information.
> >> - Format integer, enum, and boolean values according to their BTF
> >> encoding.
> >> - Mark values as "(trunc)" when the return type is wider than the
> >> value captured by the function graph tracer.
> >
> > Hmm, I really don't like the "(trunc)" If it's the real return type, then
> > it should just print what the real size is. No need to state it was truncated.
>
> Thanks, I agree. We can remove the "(trunc)" suffix and print the actual
> type information instead, for example:
>
> ret=0x5[struct:0x10]
>
> This would indicate that the return type is a struct with a size of 0x10
> bytes.
Hmm, shouldn't both the actually applied size and the true size be displayed?
e.g.
ret=0x5 (in 8 bytes, true size: 16 bytes)
Thank you,
>
> Would this be acceptable?
>
> >
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v5 0/3] Use BTF to trim return values
2026-09-02 14:55 ` Masami Hiramatsu
@ 2026-09-03 16:17 ` Donglin Peng
2026-09-03 16:36 ` Steven Rostedt
1 sibling, 0 replies; 15+ messages in thread
From: Donglin Peng @ 2026-09-03 16:17 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Steven Rostedt, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin
On Wed, Sep 2, 2026 at 10:55 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> On Wed, 2 Sep 2026 11:25:29 +0800
> Peng Donglin <dolinux.peng@gmail.com> wrote:
>
> > >> - Do not print a return value for functions with a void return type.
> > >> - Trim integer, enum, struct, and union values to the available return
> > >> value width when the BTF type provides suitable size information.
> > >> - Format integer, enum, and boolean values according to their BTF
> > >> encoding.
> > >> - Mark values as "(trunc)" when the return type is wider than the
> > >> value captured by the function graph tracer.
> > >
> > > Hmm, I really don't like the "(trunc)" If it's the real return type, then
> > > it should just print what the real size is. No need to state it was truncated.
> >
> > Thanks, I agree. We can remove the "(trunc)" suffix and print the actual
> > type information instead, for example:
> >
> > ret=0x5[struct:0x10]
> >
> > This would indicate that the return type is a struct with a size of 0x10
> > bytes.
>
> Hmm, shouldn't both the actually applied size and the true size be displayed?
> e.g.
>
> ret=0x5 (in 8 bytes, true size: 16 bytes)
Thanks, this is a good suggestion. To keep the trace concise, would this work?
ret=0x5 (8/16B)
The suffix shows captured size and true BTF size, only when they differ.
WDYT?
>
> Thank you,
>
> >
> > Would this be acceptable?
> >
> > >
>
> --
> Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v5 0/3] Use BTF to trim return values
2026-09-02 14:55 ` Masami Hiramatsu
2026-09-03 16:17 ` Donglin Peng
@ 2026-09-03 16:36 ` Steven Rostedt
2026-09-03 23:48 ` Masami Hiramatsu
1 sibling, 1 reply; 15+ messages in thread
From: Steven Rostedt @ 2026-09-03 16:36 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Peng Donglin, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin
On Wed, 2 Sep 2026 23:55:33 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> Hmm, shouldn't both the actually applied size and the true size be displayed?
> e.g.
>
> ret=0x5 (in 8 bytes, true size: 16 bytes)
I have to ask. Why do we care? Is there a use for this information?
If not, ret=0x5 would be sufficient.
-- Steve
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v5 0/3] Use BTF to trim return values
2026-09-03 16:36 ` Steven Rostedt
@ 2026-09-03 23:48 ` Masami Hiramatsu
2026-09-04 0:30 ` Steven Rostedt
0 siblings, 1 reply; 15+ messages in thread
From: Masami Hiramatsu @ 2026-09-03 23:48 UTC (permalink / raw)
To: Steven Rostedt
Cc: Peng Donglin, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin
On Thu, 3 Sep 2026 12:36:06 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 2 Sep 2026 23:55:33 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> > Hmm, shouldn't both the actually applied size and the true size be displayed?
> > e.g.
> >
> > ret=0x5 (in 8 bytes, true size: 16 bytes)
>
> I have to ask. Why do we care? Is there a use for this information?
If the structure itself is being returned, representing it as a scalar
value could lead to misunderstandings. Since we can check it is a
scalar or not, it should be noticed. In this meaning, I think "(trunc)"
is also good to me. (at least user can notice it)
Thanks,
>
> If not, ret=0x5 would be sufficient.
>
> -- Steve
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v5 0/3] Use BTF to trim return values
2026-09-03 23:48 ` Masami Hiramatsu
@ 2026-09-04 0:30 ` Steven Rostedt
2026-09-04 1:34 ` Donglin Peng
0 siblings, 1 reply; 15+ messages in thread
From: Steven Rostedt @ 2026-09-04 0:30 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Peng Donglin, dolinux.peng, linux-trace-kernel, linux-kernel,
pengdonglin
On Fri, 4 Sep 2026 08:48:08 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> > I have to ask. Why do we care? Is there a use for this information?
>
> If the structure itself is being returned, representing it as a scalar
> value could lead to misunderstandings. Since we can check it is a
> scalar or not, it should be noticed. In this meaning, I think "(trunc)"
> is also good to me. (at least user can notice it)
OK, after thinking about this more, I agree that "(trunc)" is the better option.
-- Steve
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v5 0/3] Use BTF to trim return values
2026-09-04 0:30 ` Steven Rostedt
@ 2026-09-04 1:34 ` Donglin Peng
0 siblings, 0 replies; 15+ messages in thread
From: Donglin Peng @ 2026-09-04 1:34 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu (Google), dolinux.peng, linux-trace-kernel,
linux-kernel, pengdonglin
On Fri, Sep 4, 2026 at 8:30 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 4 Sep 2026 08:48:08 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> > > I have to ask. Why do we care? Is there a use for this information?
> >
> > If the structure itself is being returned, representing it as a scalar
> > value could lead to misunderstandings. Since we can check it is a
> > scalar or not, it should be noticed. In this meaning, I think "(trunc)"
> > is also good to me. (at least user can notice it)
>
> OK, after thinking about this more, I agree that "(trunc)" is the better option.
Thanks, I will keep using "(trunc)" in v6.
>
> -- Steve
^ permalink raw reply [flat|nested] 15+ messages in thread