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=1793380403; b=PXAWUh+VAzpWg4nsKDgv3FAT8W/a7VBgD5uDzBSasgRJAS14116k0YTC+tOxSRak8GXv 7DM1ch+ixLNb7NmYxIj71+5BtBI/YX/+9MglT2YktGc8eEygsZC2gLXqNayul8vSZDWBO fxGSOGW7MzhKWJMhbGUgnw+6jEZLp0UBwe9f9Zmr1kAQzHIKa3P/5pTWQ7esI/4SZdWQu Tm3HVXCVe8jkLoh1bKHE4g46KgxxVrAKI1lE3eTIwOI0PJW8bEO28w3QNrNDBtd5r50gf 8F4rv899Lc+TR35nU0DG8DhktoOEVNVXFvo0l/Xl0kCgPbVsw6jdnoKye4OUdO1xpBQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793380403; 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=QXe+E+RdINfQkHY+Os5n/a14dX5ou5KZ8OJABuBnKpA=; b=bc0anXrDBrt1cOJYptAe6kwuCqY/0wR1EZeYDK+kSgAL6W1OLpVNw6ZUYf/wzmoVThvP SBMR8trIjPtUCwH7rSrLA1tXxYuMDyGNtx79lnk/giOuHbQIyfj06dPIJGxpHXk0mihsV S6xhdCmA4vPjsLkRBUrBdT/b+lIQOgDbGTt54bsFEaM9LCpVPYO2SWTB8fXj6hDSmQcFU +566nC+dCiq89sPJKazEC+qhE2qdKkwu4QjWDPqLtTZ6bT2vgRjucbpE1JA7866IWMbVa 9C82Jp/2DdO5hL48MhUOxjC8OUW9dee+C3ShleC9wd63HyBFmLU+6OMz58fZj8bmGXw== 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=DbGzyk9a; 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 E7B93606A337; Fri, 30 Oct 2026 17:13:22 +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=DbGzyk9a Received: by smtp.kernel.org (Postfix) with ESMTPSA id 925621F0093A; Fri, 30 Oct 2026 17:13:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793380402; bh=QXe+E+RdINfQkHY+Os5n/a14dX5ou5KZ8OJABuBnKpA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=DbGzyk9azvvZF4/Hf1MTiO384vuycPWTpofwisFowcjfo9WOO4kdW/wu1Ibqn+W6X gy8qEeDON8gi/LmAcPUpHcAM6SwwMxcc1RI5XzFx+w/cR1PUoyu5jNOX856m5HUzj7 tsTPxHh6q4pXGm3Fqfla8pk7sbXX84pxQEyv/1GypbCyzauFS0gkv/BxU+qmfUzXCD L1dr4R/iSkJQaZr/fenudyZudqY8PtXbSOyZT6+Ni/FYj4qE5UAS3UV68aVOaJWVIS jhlY31zdemO/w2q32veNVndGy1v5j2Pb6YJI/wCOqHKqV5u+Dv2WXdDfvExfzK0IFu hw9EktPxmvAJg== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.ams.internal (Postfix) with ESMTP id 044BE198003A; Fri, 30 Oct 2026 13:13:06 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Fri, 30 Oct 2026 13:13:17 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTErCCgqI31kxNLKTziv36fnXBEJjUhhbu5DiE4X/B+EDWlW7m/zWFNgj1YSweXkBU PolifZvSXcJFjYufRKMQCfH+Axb7faxt1OysaST/5q0uUjNM3zGxzIA3gFeFVcWBhKXbNW KPCqx0t+2ThS+g9I65B/SqyV4EvgT8RlcuSd8AYuiBPGNwT0icuK3QI4dKqmmyYnVc3+GT 6sN2z26Z5vHbtaohVyhAiEzg5APh/ZsY1FhYWee3mGH8aF7tJkErXhZ/+GVhIa6n2uEJBH 7u5P0K7Osx5Q9n4zMWIL1lmmrSHDOexahwyC1SzqtSVC6J0zZuS3gxQCWSSTutkbLvz9OL 1G5B0tCBk3zs4PzBncyaLxYHanwinwdtaZCqpJ6ef6jJM2nPi2PwFlt5b0F/ITt4b0h9+N izzIHz2ibHZClHnL2/8tuTURhBG1Ba2FmvoP3NwOgzaF03d1urngRk50/UaHRkfb97cyRM IAGxj9UWlUuiLNDhLWj9LLzrJRJWBrIr3BO1pnJqvr5enhEZfEYeCVvf1npM4ODEAjt8pG ARm03c556YtFsMKqSFO8pTdHu2AOabc3nN1UdP3lNk3JPopre+kBHu8NM5sit83odXXixV jTndLM0PW/1LFe8x41sowgTYQrmlsDVv97xDfCdkdL1jfY+QRBa84fdZR4qA X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 30 Oct 2026 13:13:04 -0400 (EDT) Date: Fri, 30 Oct 2026 17:13:03 +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 v2 05/47] mm/truncate: look again if a folio left the mapping Message-ID: References: <20261029-fixes_core-v2-0-a64ce7f83abb@kernel.org> <20261029-fixes_core-v2-5-a64ce7f83abb@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: <20261029-fixes_core-v2-5-a64ce7f83abb@kernel.org> On Thu, Oct 29, 2026 at 09:33:00PM +0100, David Hildenbrand (Arm) wrote: > invalidate_inode_pages2_range() skips a folio which no longer belongs to > the mapping by the time it has got the folio lock, on the assumption > that somebody else has removed it from the page cache. But the folio may > have been replaced, and then there is a new folio with the same data at > that index. > > For most cases, like folio migration, that is impossible. However, > collapse_file() only checks the refcount of the old folios, under the > i_pages lock, and relies on their folio locks from there on. That works for > users which repeat the lookup when they find folio->mapping changed. > The following scenario is, however, possible: > > CPU0 pwrite(O_DIRECT) CPU1 collapse_file() > kiocb_invalidate_pages() > read the folio (old data), lock it > refcount check > the write completes copy to new_folio > kiocb_invalidate_post_direct_write() > find_get_entries() -> old folio > xas_store(new_folio) > folio->mapping = NULL > folio_unlock(folio) > folio_lock() > folio->mapping != mapping > -> continue > > In that scenario, the collapsed folio with the data from before the write > stays in the page cache after the write has returned. > > This used to be impossible, as khugepaged only collapsed files that nobody > had open for writing. > > Restart the lookup at that index, like shmem_undo_range() does. The same > problem seems to exist in truncate_inode_pages_range() as well when > truncate_inode_folio() fails, so handle it there as well, but slightly > differently: simply check once more through find_get_entries(). > > Fixes: 1b6444331beb ("mm/khugepaged: enable clean pagecache folio collapse for writable files") > Cc: stable@vger.kernel.org > Reported-by: Josef Bacik > Reviewed-by: Rik van Riel > Signed-off-by: David Hildenbrand (Arm) Reviewed-by: Kiryl Shutsemau (Meta) -- Kiryl Shutsemau / Kirill A. Shutemov