On Tue, 9 Dec 2025 14:40:24 -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. I'm fine with fixing this but I believe if the addresses are more than 2GB apart there could be other issues elsewhere ;-) > > Signed-off-by: Ian Rogers <[email protected]> > --- > kernel/trace/trace.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index d1e527cf2aae..e6a80cbe9326 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -6057,8 +6057,10 @@ static int cmp_mod_entry(const void *key, const void > *pivot) > > if (addr >= ent[0].mod_addr && addr < ent[1].mod_addr) > return 0; > + else if (addr > ent->mod_addr) > + return 1; > else > - return addr - ent->mod_addr; > + return -1; Could we still keep this down to a single if check? if (addr < ent->mod_addr) return -1; return addr >= ent[1].mod_addr; -- Steve > } > > /**
