* [PATCH v2] tracing: Avoid possible signed 64-bit truncation
@ 2026-01-08 0:26 Ian Rogers
2026-01-08 2:35 ` Masami Hiramatsu
0 siblings, 1 reply; 2+ messages in thread
From: Ian Rogers @ 2026-01-08 0:26 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
Cc: Ian Rogers
64-bit truncation to 32-bit can result in the sign of the truncated
value changing. The cmp_mod_entry is used in bsearch and so the
truncation could result in an invalid search order. This would only
happen were the addresses more than 2GB apart and so unlikely, but
let's fix the potentially broken compare anyway.
Signed-off-by: Ian Rogers <irogers@google.com>
---
Reduce the number of checks as suggested-by Steven Rostedt
<rostedt@goodmis.org>.
v1: https://lore.kernel.org/lkml/20251209224024.2322124-1-irogers@google.com/
---
kernel/trace/trace.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 6f2148df14d9..5e2d597b4377 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6109,10 +6109,10 @@ static int cmp_mod_entry(const void *key, const void *pivot)
unsigned long addr = (unsigned long)key;
const struct trace_mod_entry *ent = pivot;
- if (addr >= ent[0].mod_addr && addr < ent[1].mod_addr)
- return 0;
- else
- return addr - ent->mod_addr;
+ if (addr < ent[0].mod_addr)
+ return -1;
+
+ return addr >= ent[1].mod_addr;
}
/**
--
2.52.0.351.gbe84eed79e-goog
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH v2] tracing: Avoid possible signed 64-bit truncation
2026-01-08 0:26 [PATCH v2] tracing: Avoid possible signed 64-bit truncation Ian Rogers
@ 2026-01-08 2:35 ` Masami Hiramatsu
0 siblings, 0 replies; 2+ messages in thread
From: Masami Hiramatsu @ 2026-01-08 2:35 UTC (permalink / raw)
To: Ian Rogers
Cc: Steven Rostedt, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
On Wed, 7 Jan 2026 16:26:25 -0800
Ian Rogers <irogers@google.com> wrote:
> 64-bit truncation to 32-bit can result in the sign of the truncated
> value changing. The cmp_mod_entry is used in bsearch and so the
> truncation could result in an invalid search order. This would only
> happen were the addresses more than 2GB apart and so unlikely, but
> let's fix the potentially broken compare anyway.
>
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> Reduce the number of checks as suggested-by Steven Rostedt
> <rostedt@goodmis.org>.
> v1: https://lore.kernel.org/lkml/20251209224024.2322124-1-irogers@google.com/
Look good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks!
> ---
> kernel/trace/trace.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 6f2148df14d9..5e2d597b4377 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -6109,10 +6109,10 @@ static int cmp_mod_entry(const void *key, const void *pivot)
> unsigned long addr = (unsigned long)key;
> const struct trace_mod_entry *ent = pivot;
>
> - if (addr >= ent[0].mod_addr && addr < ent[1].mod_addr)
> - return 0;
> - else
> - return addr - ent->mod_addr;
> + if (addr < ent[0].mod_addr)
> + return -1;
> +
> + return addr >= ent[1].mod_addr;
> }
>
> /**
> --
> 2.52.0.351.gbe84eed79e-goog
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-01-08 2:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-08 0:26 [PATCH v2] tracing: Avoid possible signed 64-bit truncation Ian Rogers
2026-01-08 2:35 ` Masami Hiramatsu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox