From nobody Sun Feb 8 20:35:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07D5D3A1E64; Fri, 19 Dec 2025 23:33:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766187230; cv=none; b=u5FdR/Ed9LTJuO5X/6A2DVSoSZcCg9tXG7XKFURQgbeFP2UdpK6ecpjyIH0OjCagysXk3dds7McnoaQJoZ2hTiwJyLAJ+j7eqIJYFPNUr6qnYt3Z+xE03EyO7uRUWfjjnBqxm2jc8RUmhvHOAYnAl579aU0z6cMeVttC+jVRago= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766187230; c=relaxed/simple; bh=DqZWmDy/Ff5J419Ueo8IfUMcfkNbg66kqcJ+0BbeOKk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=f2Uc+4/K+m/AEn+uRJTR2F1NRRcO7LZjMF3FgZE68uXpeW5rEaLrgt3kjiLDNaA6gaEnhwPuSFlIn6KN3/rQOLVkVsoAf4tAcALwmHfIQsnNdCBFBDwliox34k16eVtr5kI4vpP2D3sj8VY9fsc6jLRk+zn2vwE+Ylb4zX/3cJY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F4mUXYig; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F4mUXYig" Received: by smtp.kernel.org (Postfix) with ESMTPS id 8B853C4CEF1; Fri, 19 Dec 2025 23:33:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766187229; bh=DqZWmDy/Ff5J419Ueo8IfUMcfkNbg66kqcJ+0BbeOKk=; h=From:Date:Subject:To:Cc:Reply-To:From; b=F4mUXYigtqDGPy1Bu1bTrZMbbjJC0yDgrK7pBYJ5DS88R1+lOtJc/05EFbGLMjv+N dyCDg7phmP6AI/qqlJbvp34apbB04HYDf/8xfoLQCOEw8Ts+t02DALj0GKNH6bcLyJ TO+7RAMMoCVM3u5B2n7vzOCtBKyzOs4OvooxdqX/l7CIPbAV+EqnFpU1wzBr6+nnp+ +85gOTQZbZwBt9/Qpca9mZmOs9/zof24jVT/mWAbA/gsJyb0hp3ZhqNu7mrugXo6e6 q58dN8J1aXFvMF3HX/1Y4GTh9QXSwsPijwL4vXEKJUMHS+zPUSOW2mR6RtxwU9K20X DAaouTUzxM0sw== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77845D78797; Fri, 19 Dec 2025 23:33:49 +0000 (UTC) From: Dominique Martinet via B4 Relay Date: Sat, 20 Dec 2025 08:33:21 +0900 Subject: [PATCH] netfs: fix folio unlock collection end point Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20251220-netfs_mmap_corruption-v1-1-da4a2ce87e18@codewreck.org> X-B4-Tracking: v=1; b=H4sIAAAAAAAC/x3MQQqAIBBA0avErBN0oJKuEhFiY80ik7EiiO6et PyL9x/IJEwZ+uoBoYsz77GEqSvwq4sLKZ5LA2psDKJWkY6Qp21zafK7yJmOIlSLZGwXgkfrodg kFPj+v8P4vh+XyAOgZwAAAA== X-Change-ID: 20251220-netfs_mmap_corruption-62e187ffc28c To: David Howells , Paulo Alcantara , Christian Schoenebeck , Christian Brauner Cc: netfs@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, v9fs@lists.linux.dev, Dominique Martinet X-Mailer: b4 0.15-dev X-Developer-Signature: v=1; a=openpgp-sha256; l=3691; i=asmadeus@codewreck.org; h=from:subject:message-id; bh=bnehbcpLm5UV7kOLOAuC9015mdwwP/1OVmMXJJYp4+A=; b=owEBbQKS/ZANAwAKAatOm+xqmOZwAcsmYgBpReDZTHI58pNcDP7ONjbVTvPcCmbidQsITsxhZ tagjjNuBgWJAjMEAAEKAB0WIQT8g9txgG5a3TOhiE6rTpvsapjmcAUCaUXg2QAKCRCrTpvsapjm cJKFD/4gdgI+gIbj9zSnPNdgrT/kLxxed+Z3o5ZPyzY1G2mM8Y7QBfPOkC2DmDeNjv5X2+sU0OS Xu8Rfl4nFyvsIQ482o8zqxCF7ey03kKpxqru4+tNtp5XLVgRWWLLtS3axq74BN5uhUx2o5ZUdnl kcrdmWOYNwHhf9sKxNe+wUphHrPN412lZh9azCMc8rJwkEyD6lvFZkdHKmzTsVDPkNHSipBEVGB BlRM1lSkVavC4ZE8tg/W1S2AwhkYfzOTYnNJsV9bCqb+HbNx8jLiKc/4/62ZTA8bd3HOG8KrWE2 eIMedY4hLUYa511NHTPyDXgg5w/4ZTk3JOU20Eh+y7wYpvXvWzeboMxRx3BWSNd3UNGLTw7cuXs xqLdW1EOAjUZKusZgsOrET/PJiB/xBxd8QE1Lo3Sgp8nBDBtZncEGbblebQVf5h1o5eh19HGQbp +hKpOQvnljMrWKtQ7d5VlG/nKQ1qT5DLg0eVcrXENVRFVm2jHxKjuDsOmIZnQuZWv7kPhsS79+6 L+9mqYgadhE34xJ5t001x6Xu0zvp1DeQcTnJEr8x+Q+ZfvbKBO8JQ36Q4fysxLiMVZiI4s/EoNX qVtupRpWrv/QbbLK1FpvahYTTN1CTFvdphKnpaq+HU3i8e+UYkBDTtNGJSYRgvEs3bBxb+Eos9V Dk0IaxH0TUDXWhA== X-Developer-Key: i=asmadeus@codewreck.org; a=openpgp; fpr=B894379F662089525B3FB1B9333F1F391BBBB00A X-Endpoint-Received: by B4 Relay for asmadeus@codewreck.org/default with auth_id=435 X-Original-From: Dominique Martinet Reply-To: asmadeus@codewreck.org From: Dominique Martinet 9p suffered from a corruption in mmap-heavy workloads such as compiling with clang (e.g. kernel build with `make LLVM=3D1`, failing with random errors on mmaped headers and clang segfaults) David Howells identified a problem in the netfs trace of such a crash, below: > We unlocked page ix=3D00005 before doing the ZERO subreq that clears > the page tail. That shouldn't have happened since the collection > point hasn't reached the end of the folio yet. netfs_collect_folio: R=3D00001b55 ix=3D00003 r=3D3000-4000 t=3D3000/5fb2 netfs_folio: i=3D157f3 ix=3D00003-00003 read-done netfs_folio: i=3D157f3 ix=3D00003-00003 read-unlock netfs_collect_folio: R=3D00001b55 ix=3D00004 r=3D4000-5000 t=3D4000/5fb2 netfs_folio: i=3D157f3 ix=3D00004-00004 read-done netfs_folio: i=3D157f3 ix=3D00004-00004 read-unlock netfs_collect_folio: R=3D00001b55 ix=3D00005 r=3D5000-5fb2 t=3D5000/5fb2 netfs_folio: i=3D157f3 ix=3D00005-00005 read-done netfs_folio: i=3D157f3 ix=3D00005-00005 read-unlock ... netfs_collect_stream: R=3D00001b55[0:] cto=3D5fb2 frn=3Dffffffff netfs_collect_state: R=3D00001b55 col=3D5fb2 cln=3D6000 n=3Dc netfs_collect_stream: R=3D00001b55[0:] cto=3D5fb2 frn=3Dffffffff netfs_collect_state: R=3D00001b55 col=3D5fb2 cln=3D6000 n=3D8 ... netfs_sreq: R=3D00001b55[2] ZERO SUBMT f=3D000 s=3D5fb2 0/4e s=3D0 e=3D0 netfs_sreq: R=3D00001b55[2] ZERO TERM f=3D102 s=3D5fb2 4e/4e s=3D5 e=3D0 This patch changes the end condition for collecting folios that have been read, from "is the IO over?" to "have we read up till the end of the folio?" (collected_to >=3D fend), which delays the read-unlock to the "ZERO CONSUM" step after the page tail has been zeroed Reported-by: Christian Schoenebeck Link: https://lkml.kernel.org/r/2332946.iZASKD2KPV@weasel Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use o= ne work item") Signed-off-by: Dominique Martinet --- A few notes out of order: - I don't really understand why this actually matter -- sure, there'll be junk after the mmap region ends, but why does this cause a bug? Since the folio is unlocked the zero fill operation ends up zeroing the end of another page? Well, either way there's no doubt that the early unlock was a problem... - I have no idea how to test that this doesn't break something else by not unlocking a page that should be unlocked e.g. something that wouldn't need zero-filling (partial refresh?) -- I don't *think* we have anything like that, but I don't actually know, so pleae don't trust me too much here... Nothing I normally test on 9p broke so it's probably not too far off though. This has been broken for about a year so I guess there's no great hurry at this point, but any extra pair of eyes would be appreciated... (Christian S, I've tested as much as I could think of, but any extra validation would be great too if you have time!) --- fs/netfs/read_collect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/netfs/read_collect.c b/fs/netfs/read_collect.c index a95e7aadafd072edbb0f1743e0020eaf65b7d1ed..7a0ffa675fb17aa7431c0fd6cc5= 46deb0be0be22 100644 --- a/fs/netfs/read_collect.c +++ b/fs/netfs/read_collect.c @@ -137,7 +137,7 @@ static void netfs_read_unlock_folios(struct netfs_io_re= quest *rreq, rreq->front_folio_order =3D order; fsize =3D PAGE_SIZE << order; fpos =3D folio_pos(folio); - fend =3D umin(fpos + fsize, rreq->i_size); + fend =3D fpos + fsize; =20 trace_netfs_collect_folio(rreq, folio, fend, collected_to); =20 --- base-commit: b10e94717f7e295d7ff6ce08249f7e31b630ef1b change-id: 20251220-netfs_mmap_corruption-62e187ffc28c Best regards, --=20 Dominique Martinet