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=1794225855; b=vS7+2wDjL0cng9rsahSAzdVAPw3yxuQeu5pPPMEa+1c8NPp6n9sbqncfHZ7/+fwD8GaB 9z4DtnF54h3bgLu/mYrcbuB25ESh50inPsDnSPD2JSNxP4OEDctp3GSEVT39D/OZcIM2A ArLVOsAOn6LDyEPTV8KMulpxpGvmzMu0sua961yfasXxlOu0dix3gIdm1DQ7yfQ3ePFqe DismraXT5kupUKMO4pnmlRe+nmEmFls94VI0NscFEyBEN3GBbfhcw0hUqSGbgfSFDMq+P 4+auXoXwoXJaik8skN0nZRS7Tt6RkQTBzDWEckU7LTHM3QaxmzF9Z38OxiCs5IduWIw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794225855; h=Received:DKIM-Signature:Received:Received:X-ME-Sender:X-ME-Received: X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID:Received:From:To:Cc:Subject: Date:Message-ID:X-Mailer:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding; bh=6KtNQnmIxI0QenYCQzZ2p4IsyzDnjmwEuXaOE3U5xFI=; b=UaOUc5cct5MbRx0F4+Ia8oU1pT75d7Xrc1aZTUwHBtsFYxnMfWAtVZpFr9gqaXNHZqVk Ad99WkbQaAcqBElSnTMz49lG+/Dd/DWzuj9pFk6b2TXsV6AzCNd5P56U9eHeEZ0Z3DTia 4MmjXuZyNtQ0fbq3YGxK1fnCL/L2h+Mbw2rBKFDSC14zgksn+SPAtlowToEo7L7Uyy5gw /BPb2Ak+OT6aGjOIh+OEUFPafCubvyQ6YrOKnfp7YwYBFqLIPYzBqPrirrga8exoudSug HofHw2Z5IgftDBPtNrYLrb6UtLhrXp+fVT/5vZnZo2gVDEjbQCcw4Ta4sjSDFG3ALQg== 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=maqChVHY; 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 D5810606A32A for ; Mon, 9 Nov 2026 12:04:14 +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=maqChVHY Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03C851F008A1; Mon, 9 Nov 2026 12:04:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794225854; bh=6KtNQnmIxI0QenYCQzZ2p4IsyzDnjmwEuXaOE3U5xFI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=maqChVHYt7UHd0PkqZXlPhMF5EF/+k7GB1eNh7F8HqF9xvpV8sXRBNefl0fmFp1u4 PKUad7AQdbEH5nmXexaX6va6BgpSOUGNMTn9Erlv2zwWhgE7QSWf+ldKMjnSZ241gg gn4YGN9cIXIkeXxROiliDbE69JhFp9EsbEQkZOI4b8j3PXRz/jqspQclGkuwObYwLc yZzTUlqzJEKHIDRMlBS4liICJervpwke9NhZEkgMaVVwegBiB04frU31JTPfzI/jOx /ZiUXACm3w/5n45d5s+tWYFAGYc/wA5sa4dpArLN+z/kZ5/f1zE+LhHpp1WNAlAxvW IC8fgzx0LH+Zg== Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfauth.ams.internal (Postfix) with ESMTP id 35F691980047; Mon, 9 Nov 2026 07:04:10 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Mon, 09 Nov 2026 07:04:11 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFgcJX3QqaptuagcgdnHFOsQz9wWiwGd7fgbWtGQNXmmbQfltLWg6boYc6d5AKRlG aOxWDcvYi2kECOnriHvC/JUlDnzbmMpNexALRZD+bYBHTIomNBZGGdCvXnp7cpCw3lorG4 mGkrJknDCty1x7KsL8HGILfh1AM4KqxL7tur3y4mpHTRwUy6di6Bu27Pr9NACBQYUpbMuF HWK/8Qq13pFWGE6fal96QlsPbVBll7/chUmg6CwRPtzvPHt+donq3X9nQyFhwbSOM0N+Io m6CjDIVHaS9HXPRZ818OnENAcELGySEuqqm38mAS7EtGpMa7cAB0pgdfGnkGeISrlEhMJK KuMC6q5DLaHRgyX/hBgjUKsMUPqtZvjgceEDkznhIAplP8bkScP9qG8/uxFiNocDvLdG9i N8Hy78HdgidFLTVI7NDYd2CVeoCAPHnrZoGw2UIa29B2Yp6pRijzZz0nCJPRSvjAqI3iZ9 bzRWmV0UzyvP4GPE6jgzctKeHjJE3QxKwRHZzzwXWm86MSzEKA8+sYXUiwyJQ9b5dWatt3 h/DZ1MoPGzMIHR9gCGVnGZsBTU2h6rGOFDUdhPxkjvGRdErnEhyPoSNtUpHkceGOd49bZu U9tWGzr3emLA7R+XNz5O+UrnfvFHgUmsFRCq1vM3BUqxqdafNXiPI4K1JSEQ X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Nov 2026 07:04:09 -0500 (EST) From: "Kiryl Shutsemau (Meta)" To: Andrew Morton , "David Hildenbrand (Arm)" , Pedro Falcato Cc: "Kiryl Shutsemau (Meta)" , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , "Matthew Wilcox (Oracle)" , Hugh Dickins , Chris Mason , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Sashiko Subject: [PATCH v2 1/2] mm/memory: recheck PG_uptodate after ->page_mkwrite() Date: Mon, 9 Nov 2026 12:04:01 +0000 Message-ID: <20261109120403.82361-2-kas@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20261109120403.82361-1-kas@kernel.org> References: <20261109120403.82361-1-kas@kernel.org> 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-Transfer-Encoding: 8bit do_shared_fault() unlocks the folio around ->page_mkwrite(). Writeback can lock it in that window, fail, and clear PG_uptodate with the folio left in the page cache. ecryptfs_writepages() does this when encryption fails. filemap_page_mkwrite() relocks the folio and checks only ->mapping, so the fault maps a folio that is not uptodate: CPU0 CPU1 do_shared_fault() folio_unlock() ecryptfs_writepages() folio_clear_uptodate() filemap_page_mkwrite() folio_lock() finish_fault() The next read(2) or fault on the folio reads it in again from the file, over anything stored through the mapping in the meantime. Those stores are lost. Recheck PG_uptodate once ->page_mkwrite() returns with the folio locked, and retry the fault if it is clear, the same way filemap_fault() retries on a cached folio that lost PG_uptodate. Skip folios outside the page cache: driver pages from ->fault() never get PG_uptodate and would retry forever. The check stays out of do_page_mkwrite(): wp_page_shared() calls it on a folio that is still mapped, and a retry there would fault on the same PTE forever. Reported-by: Sashiko Closes: https://lore.kernel.org/sashiko-outbox-202966@kernel.org/ Signed-off-by: Kiryl Shutsemau (Meta) --- mm/memory.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/mm/memory.c b/mm/memory.c index fe72e66c9c2e..cc1d0b7d15c7 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5613,6 +5613,18 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf) return VM_FAULT_OOM; } +/* + * A page cache folio that is not uptodate holds data that was never read in + * or cleared, and mapping it leaks stale memory to userspace. + */ +static bool file_folio_not_uptodate(struct folio *folio) +{ + if (likely(folio_test_uptodate(folio))) + return false; + /* Driver pages from ->fault() never get PG_uptodate */ + return !folio_test_anon(folio) && folio->mapping; +} + /* * Either the VMA lock or the mmap_lock must have been held on entry * (see FAULT_FLAG_VMA_LOCK) and may have been released depending on @@ -6163,6 +6175,16 @@ static vm_fault_t do_shared_fault(struct vm_fault *vmf) folio_put(folio); return tmp; } + + /* + * The folio was unlocked for ->page_mkwrite(). If it lost + * PG_uptodate meanwhile, retry the fault to read it in again. + */ + if (unlikely(file_folio_not_uptodate(folio))) { + folio_unlock(folio); + folio_put(folio); + return VM_FAULT_NOPAGE; + } } ret |= finish_fault(vmf); -- 2.54.0