Re: [PATCH] mm/kmemleak: fix scan period truncation on 32-bit platforms

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] mm/kmemleak: missing Fixes trailer and duplicate subject in
  commit message
--

commit 807561d4895dc6a557b90ff7973974cbbb93309d
Author: Shao Mingyin <shao.mingyin@zte.com.cn>

> mm/kmemleak: fix scan period truncation on 32-bit platforms
>
> mm/kmemleak: fix scan period truncation on 32-bit platforms
>
> kmemleak_write() converts the scan period from seconds to milliseconds
> before clamping it to UINT_MAX. On 32-bit kernels, unsigned secs and
> MSEC_PER_SEC (1000L) are multiplied in a 32-bit unsigned type. The result
> wraps before the clamp can detect overflow.
>
> For example, scan=4294968 produces 704 milliseconds instead of the
> UINT_MAX millisecond limit. Perform the multiplication and keep the
> intermediate result in unsigned long long, preserving the existing
> 64-bit behavior and the later msecs_to_jiffies() clamping.
>
> Commit 54dd200c5a25 ("mm/kmemleak: fix possible wrong memory scanning
> period") added this clamp, but it cannot work after a 32-bit multiply
> has already overflowed.
>
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>

[Severity: Low]
Since this fixes the scan period clamping logic, should the commit message
include a Fixes: trailer:

  Fixes: 54dd200c5a25 ("mm/kmemleak: fix possible wrong memory scanning period")

Also, the commit subject line is duplicated as the first line of the commit
message body.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115004702358r2RJLihSrqbK4dr026bcI@zte.com.cn?part=1