On Wed, 28 Jan 2026 17:33:16 -0500 Sasha Levin <[email protected]> wrote:
> LLM Generated explanations, may be completely bogus: > > The original buggy code was introduced in v6.15 and later. It's only > present in 6.15+ kernels. Interesting self discussion from the LLM. > > ### 8. SUMMARY OF ANALYSIS > > **The Bug:** > - The `cmp_mod_entry()` function uses subtraction of two `unsigned long` > values and returns the result as `int` > - On 64-bit systems, if addresses differ by more than 2^31 (~2GB), the > truncation from 64-bit to 32-bit can flip the sign > - This would cause `bsearch()` to make wrong decisions about search > direction > - Result: potentially incorrect module address lookups in trace data > > **The Fix:** > - Replaces arithmetic subtraction with simple comparisons > - Returns -1, 0, or 1 directly based on comparisons > - No overflow or truncation possible with the new code > - Logic is more readable and provably correct > > **Stable Criteria Evaluation:** > 1. ✅ **Obviously correct and tested**: Simple logic, reviewed by > maintainers > 2. ✅ **Fixes a real bug**: Yes, a potential comparator correctness bug > 3. ⚠️ **Important issue**: Moderate - unlikely to trigger (requires >2GB > address separation) but could cause incorrect trace output I purposely didn't add Cc: stable because there's basically no chance of two modules being more than 2GB apart. > 4. ✅ **Small and contained**: Only changes one function body (~6 lines) > 5. ✅ **No new features**: Pure bug fix > 6. ✅ **Applies cleanly**: Should apply to 6.15+ kernels where this code > exists > > **Risk Assessment:** > - Very low risk - the change is small and the new logic is simpler > - The original code has a provable bug (integer overflow on truncation) > - The new code has no such issues > > **Concerns:** > - The code only exists in 6.15+ kernels (introduced March 2025) > - The bug is "unlikely" per the author (requires addresses >2GB apart) > - No known real-world reports of this actually causing issues > > ### DECISION > > This is a valid bug fix that: > - Fixes a real (though unlikely to trigger) bug in the comparator > function > - Is very small and self-contained > - Has been reviewed and acked by the tracing maintainers > - Has near-zero regression risk > - Applies to 6.15+ kernels only > > The fix is surgical, obviously correct, and addresses a potential > correctness issue. While the bug is unlikely to trigger in practice > (addresses must be >2GB apart), it could cause silent data corruption in > trace output when it does trigger. The fix is trivial and risk-free. > > **YES** But I see the bot considered the same thing, but because of the risk factor it decided to take it. I have no issue with backporting it (I did label it a "fix"). I was actually wondering if the bot would notice likeliness of it not happening. It did, but decided to take it for "correctness" reasons vs risk factor. Nice, -- Steve
