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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Sun, Nov 15, 2026 at 12:47:02AM +0800, shao.mingyin@zte.com.cn wrote:
> From: Shao Mingyin <shao.mingyin@zte.com.cn>
>
> 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>

NAK.

this is generated by some AI slopper's script, spamming the kernel. The
patches I looked at were wrong/broken, so no to anything from this person.

They've sent 300 mails in under four weeks spanniing: ata, scsi, target,
ufs, nvme/nvmet, ubifs, ublk, zloop, dm, md, mmc, virtio-blk, mfd, gpio,
pwm, spi, PCI, ASoC, ACPI, net, vfs mount, block partitions, and now mm.

and 17 series across 7 subsystems over the past 23 hours.

We need a way to ban emails from people like this...

--
Cheers, Lorenzo