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=1794677640; b=3FS14C8Y1oHkUEHS81X8FugVuOI4U64uF/GCjldIAwfSK9LdzUdBNjvXLifgvldSk5Fy d7hiXb+uE3PHrOV7SBnxKrDPNc2Ia1BLh72+HZxEXnNswaJTVE7NxrKdueiA4csLcGbeq 8csTY4oGUk/ArkJIWooyuwiXKDUUOXZDfhlyKcKZS0XCbUc6GWfPJtE/zV+C3I8caC2+B IMoM9V5INmlJXzmdGAnuk7cJE3DanwuRJNdohKeUEaIR0vRbF9yAvu8DTcLXc+RTPfO7Q vGkCC2IOyEhYmTSVWpfmbWtJHTD4oPck2WXOmQrC5AGlapn0oTBOt/ED21HmIYJOmVw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794677640; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=KFpXgHITgTKpJjTXjtCWWLVB9Sr0Cws6b+lQmt5jk1U=; b=5MRKmAgc4XCiwhqaOUrRJ0W9UrL0d8Aut4QzMHaDVz7KPOuiDz5uVd7GdBu0NmaHJXei 10aUMsCeFtGZOi8g6lHA6cfFGu1dO1TkiPPbLh0pHi4hpVbDUUtmzsiSZJx5XkUkr/jc/ qxzhSEBXU1gd187Oet4n+ABDRxv11M5o4a1Yv7ZNOaP2S/k2vzw1Gj9xSJL2QHysXI7GJ pAySs3ZNFU19UldKpT1Yq1mHBdI263fBCYS5/oNqZergcQv/v6wQASTg/STfX8Kzajuje zrQ4ep5/EJflUXlaiokV24eqqDGs3i4cM49DgQDh6noQ5lqfoliyDdupKmt2dLynl1Q== 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=FsLNePpJ; 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 3CDA3606A323 for ; Sat, 14 Nov 2026 17:34:00 +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=FsLNePpJ Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52F041F000C4; Sat, 14 Nov 2026 17:33:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794677639; bh=KFpXgHITgTKpJjTXjtCWWLVB9Sr0Cws6b+lQmt5jk1U=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=FsLNePpJ67WtMpcBtQy5xfKYA8q8BcgKSYhg/XRLaH2t1/FF8hLR7UoKdJraBOxcE mUcuBh8eE6I3Gc2ugyua9WSmZ0AA6V1bC+vYLhS4By7aboCtudxrYBWFOWjmiIXlm9 3yXMG6/bWUV1Dl2RBYP30+uk09PQc8G+doiN/1A3LmSQIzvB6IPQ6E81WOae4ZgXep Ex96VsoDe7GoeMgLCOzG4JLml+P/7byQ/edBRG3T2El3sOLbwfwWxhqn02s3DiYmGu KHVRl7BwzAImFEfP6iUMtKE62oFQTpdqd/amfbZSaHcD/7ElZWwQ3jrBMZkZw9loOk LgSv62x2CLRfw== Date: Sat, 14 Nov 2026 17:33:54 +0000 From: "Lorenzo Stoakes (ARM)" To: shao.mingyin@zte.com.cn Cc: akpm@linux-foundation.org, david@kernel.org, linux-mm@kvack.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/util: fix off-by-one when checking folio index in snapshot_page() Message-ID: References: <20261115004657890Pz8ERDf5nCtE-B6M7KFzu@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: <20261115004657890Pz8ERDf5nCtE-B6M7KFzu@zte.com.cn> On Sun, Nov 15, 2026 at 12:46:57AM +0800, shao.mingyin@zte.com.cn wrote: > From: Shao Mingyin > > mm/util: fix off-by-one when checking folio index in snapshot_page() > > snapshot_page() computes the page index before copying the folio state. > If the folio changes between those reads, the index can equal the copied > folio's page count. Valid indices are strictly less than that count, > but the current check accepts equality and marks the snapshot faithful. > > Use >= so that this inconsistent snapshot is retried, or falls back to > the unfaithful single-page representation. This also avoids reporting an > out-of-range folio index without the corresponding dump_page() warning. > > Fixes: d863a12108f2 ("mm/util: introduce snapshot_page()") > 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