From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794677589; b=iYPiP04Qof1Lykm4osjOi4hvYkTngsWpq4t86bwSqmEzropSfvxq7RWcSyxVLFCp6V3j 8sFVnjinowhfy0Eu/3zj9zwzQmmd2RehQ7YLRjTaHMEYytTvXVu2M5yfVtIzGeSjeUWE6 xMtQ+lmcy/db4P1o5kazDWrLLSbEj726lgZlnFu0rSnD6HAYzhO0fYlydYbGrYYQXZQIx azqxdnxp5At+qgR8PE8Teexnw57kUzlXprDdnIP75Gl2rjnyqS9zm1F9IN+XUwSwLlqAA IrjuYNlYhUqCtWQQgFiS+7nxl2z51Jb5taC6CwzpntfFUs/lAi76MveDDQ1hmUuzrMQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794677589; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=1aF6FG/8A8GNSEhifnB76peEauYvwhc3Lhh2bB6umMo=; b=LL6vXkucgpGrEFuakiyr33fhpjGCTkcDaCPQvt3j1cbWtp/W0PMHR5ZoOuvOSskQY07e MzmBjTV4hC7G/8wqMOpvFLNlS/W9Em2HZo/15sn8ZazxfJt0tDFUczyFw6oPRRqwYkLIz R9jXfW9HcdmvhTS6uZztHqrvhodxTUabVrTNwQtECxYzX+wtqP477RaFp9g8gT71AIpPW U5jvkRRNKDf7qg65j8VbteFjIe81cfd1DJ/ctoytQhu+ZyOakGX0mfjj9fK8+xzh7P42X 40eqXoecz6cHUcI4wOxqKFHNuPErEfrI6/10jNReDBXUlrl1S634priAfzBOUpD3U4Q== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=CC4g0DhR; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 451AB606A329 for ; Sat, 14 Nov 2026 17:33:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=CC4g0DhR Received: by smtp.kernel.org (Postfix) with ESMTPSA id 541151F000C4; Sat, 14 Nov 2026 17:33:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794677588; bh=1aF6FG/8A8GNSEhifnB76peEauYvwhc3Lhh2bB6umMo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=CC4g0DhRkW0DeJDtpn706QZWi/HUMQpuW3IfDjK3Nioulri574vN0BEOuOCzLEX0I hG8CHO8NhSwRLAftY6Yi/ENg6d/hbIwvjnnpPpwvOFX2J4oLQulgyLk2bHXV1QgWwc 3cvYrwB/d4QSZWWOP/nC57raDQvh0wenbsXW2k0Ro9PY1Ww7kQDolFpvmgCVCok4rS 3KyjVPCClhNm5+sFeKfLnxm5MhuiCX+MaRb6p3dZr9Pe8gHaisIFUgCTglyaY/jGqj 04Lz4mnvNMNToXXnifofD5WoXXNk3tC7au3I7cIlVqlA0L0QSWFZHAf5GDvqtKNiVD 3CRYU+nZajhhg== Date: Sat, 14 Nov 2026 17:33:04 +0000 From: "Lorenzo Stoakes (ARM)" To: shao.mingyin@zte.com.cn Cc: catalin.marinas@arm.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/kmemleak: fix scan period truncation on 32-bit platforms Message-ID: References: <20261115004702358r2RJLihSrqbK4dr026bcI@zte.com.cn> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261115004702358r2RJLihSrqbK4dr026bcI@zte.com.cn> On Sun, Nov 15, 2026 at 12:47:02AM +0800, shao.mingyin@zte.com.cn wrote: > From: Shao Mingyin > > 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 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