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=1793284737; b=qoLNL4wyr3b5HjeLuVnjvDHoQeHzSPrLyjsqVtorDOiilsaGX8+k7dnVSxI6sY3M6uDf /lBYVIy7BA1wUmGxwDdxxVY40frr+y9Ho02njWuwDumDNDqZuBbpHL08l5B0rHnQjr8mI B5Rvy+msNRydvMcXyKIIfkAIfk4rQiz9+E8lc/syrCRRswuF/ysGAceKJillgESR2lpaE TsNH4+A8nTFhf+LxyU2RmoRVHyx/OLn8smESbNAgr3ltcfnKjw42cpuBgVB8mI3nllE5X zvqOWXuf/wTtUbO0CKupjpXZbLSGR0JZsHGxkZ7D942ReAZlt4Qj/sguYxL9ytEeWew== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793284737; h=Received:DKIM-Signature:Received:Received:X-ME-Sender:X-ME-Received: X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID:Received:Date:From:To:Cc: Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; bh=2c21uwKaYBeCH/6VWYVmdV37CjIv9I8O7v1n1RARYlc=; b=ZdXiw4hYuYyAy7S5U6ds/4Ryqmrs76BXiLjsUuMLuxPVTAc83zT9Qj29nY2Y1nKAH7jU RW4Cq5fIhsRTXDF1B1fYFut7UrxhMWVIoxvXO5OETS7FSnMIJ3wAI/McT1PZtMFzTvJxo awAJxmebkSr8t/GDbL/7O5xqmKIOdCZed0trg7SLhoOGh+85A4SzYFKUchDJ6ZjQnscy9 3rRCRPd8EerSbRAK/TQ211g60d1+8lbVT2kocMb8E/VBua3XnsNmijFV6oY+1yd488O+r +d+nWDh2O1nZljL5Vb6qxszgLNc+g9Mtv3ZyaORZwRsBXE5W8/GwVlRpT9HXVlUe51Q== 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=K0brHDEn; 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 A10EF606A31D for ; Thu, 29 Oct 2026 14:38:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=K0brHDEn Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3215B1F01828; Thu, 29 Oct 2026 14:38:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793284737; bh=2c21uwKaYBeCH/6VWYVmdV37CjIv9I8O7v1n1RARYlc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=K0brHDEnuqQhWXXYwMNetBZUAc9caKJqX54Ex7mnt7lYb+4rnUHMtKeOUVJbecR6x sU0SbnzI12FFBeRuUcMc04YgqkUxqt+Og5JePTeMUn3GA6A3hIokcUSO36BjTKAP5e CL2I7WQTTjojIxVQi3LwjszYjYWYrlVjF5Fb/9yNir02Kvi2rPyg4lNYVhqCE1WQHk MpdDPFcPjSw2qX0fp7fRvkj+oyK9lgURQmvvPWOzj8QhrT8/MyVK+jHdpEsoGBz8hG Cth6sJljtHxnR/+ulKV1yvr9IuYofFaAThTnn2m3vcuty9CcWNjwWFKPDayOAr7kXL KgBBXha8ZupzQ== Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfauth.ams.internal (Postfix) with ESMTP id 90D74198003A; Thu, 29 Oct 2026 10:38:42 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Thu, 29 Oct 2026 10:38:52 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE1JQNUF9PdrYwdkwAFugjPequB2b5GkpJPbUhdIUOmy1kLSEa6ffoj9Hd7ym4nlQ 6c+qEKz7XJF2dLx7oRdUpSkj4b254h51buP1yG18if3BMK6dmDzoqWHXykJimalZrh/4rJ SsEcPs20Bpv09nkNrhslFOxZz8uVj4cr4k8j9ijyh/XBoKSuXv1p6X+IUvsZtCJM8WfE5l J8Jz1TAy0V7XkJjA0KShHBsQLkX2f1gt0hjvq9NIXYrKVkv94AWot0YqZ8U/rCanLqw0Ux nS0CeNSxqNiXe8tVlryBNbvyzw1vi48KrHlrtPOhBitk5kNMfGdDxWgDHV9ZsVHIb2WImx TwMS9d/rsrEBKfxdMOSo+pyt17kDFmy35KxazECXh7bqp4EIa3Fk+VlfdJbpj5ufyo9OA3 cdQZdLaECR6tTTcrvOAoZ6f8OJwIL1rN6yn5DB/KWiV2ZbluJEJnlB1arcSbKxNW52myVz 06ljSPiBv3EbnUa1kWyazn91XogClvtyE0OEqlsAQ638VYboUKTsedBBE1LJXDi269o4Qw Jo3zIY6bYwxBR4IQ787plmSM0ewfmHIgzlo56dB5tRTuxgWJ6cyyj7nxSfxzCvAomiCOef /nGdMay+iI3nqioWP+xUE4QMzHjon9lRnR6vq2mNaqsZfMczKJ9UC07yYVvQ X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Oct 2026 10:38:40 -0400 (EDT) Date: Thu, 29 Oct 2026 14:38:39 +0000 From: Kiryl Shutsemau To: "David Hildenbrand (Arm)" Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Baoquan He , Baolin Wang , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Kees Cook , Peter Zijlstra , Jann Horn , Pedro Falcato , Hugh Dickins , Pasha Tatashin , Pratyush Yadav , "Matthew Wilcox (Oracle)" , Jan Kara , Zi Yan , Lance Yang , Rik van Riel , Harry Yoo , Alistair Popple , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Matthew Brost , John Hubbard , Peter Xu , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Oscar Salvador , Minchan Kim , Muchun Song , Xu Xin , Chengming Zhou , Chris Li , Kemeng Shi , Nhat Pham , Youngjun Park , Gregory Price , Joshua Hahn , Rakie Kim , Ying Huang , Jason Gunthorpe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-cxl@vger.kernel.org, stable@vger.kernel.org, Josef Bacik Subject: Re: [PATCH 05/46] mm/truncate: look again if a folio left the mapping Message-ID: References: <20261027-fixes_core-v1-0-6f74bec9a5bb@kernel.org> <20261027-fixes_core-v1-5-6f74bec9a5bb@kernel.org> <2f2ef336-2186-4f20-b7f5-565e60471bda@kernel.org> <7fab2115-6c44-43b1-b03b-8ce4a37ffe32@kernel.org> X-Mailing-List: linux-cxl@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: <7fab2115-6c44-43b1-b03b-8ce4a37ffe32@kernel.org> On Thu, Oct 29, 2026 at 03:18:23PM +0100, David Hildenbrand (Arm) wrote: > On 10/29/26 12:37, Kiryl Shutsemau wrote: > > On Wed, Oct 28, 2026 at 10:45:34PM +0100, David Hildenbrand (Arm) wrote: > >> My brain hurts, does the above make sense? > > > > Yes, I missed that the loop only goes back to start when a lookup > > comes back empty below end. When the last batch reaches end, it exits > > without another look. It doesn't need the split either: any punch hole > > whose last page is in the page cache gets there. > > > > That exit looks unintended to me. b9a8a4195c7d ("truncate,shmem: Handle > > truncates that split large folios") turned the "if (start >= end) goto > > out" early exit into the loop condition. Before it, the loop went back > > to start until a lookup from start found nothing; Hugh kept that on > > purpose for hole punch in 792ceaefe621 ("mm/fs: fix pessimization in > > hole-punching pagecache"). > > > > Restoring it is enough, and makes the "restart to make sure all gone" > > comment true again: > > > > + if (start >= end) > > + return; > > + > > index = start; > > - while (index < end) { > > + for (;;) { > > > > Then a replaced folio is found on the next round, and truncate needs no > > special case for it. > > > > But that's then another lookup even if not really required? > > Why do you thing that is that better? > > I agree that the code is simpler, but at least it's consistent with the other > handling. The extra lookup only happens when the second loop had work to do. Normally the first pass removes everything, the first lookup from start comes back empty, and both versions stop there. When the second loop did run to end, it costs one more lookup over a range that is now empty. What I like about it is one way to look again instead of two: the loop already goes back to start when the last batch ends below end, and the patch adds a second way for when it ends at end. truncate is not like shmem here: shmem_undo_range() stops after one sweep on hole punch on purpose, so it needs the rewind; truncate was meant to sweep until nothing is left. Your version fixes the bug too, so I'll leave the choice to you. -- Kiryl Shutsemau / Kirill A. Shutemov