On Wed, 7 Jan 2026 16:26:25 -0800 Ian Rogers <[email protected]> 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 <[email protected]> > --- > Reduce the number of checks as suggested-by Steven Rostedt > <[email protected]>. > v1: https://lore.kernel.org/lkml/[email protected]/ Look good to me. Acked-by: Masami Hiramatsu (Google) <[email protected]> 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) <[email protected]>
