From mboxrd@z Thu Jan 1 00:00:00 1970 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 C05FD221540 for ; Sat, 24 Jan 2026 22:20:20 +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=1769293220; cv=none; b=IEPAznX8BW8Gv23sQYOAf1q+lf9tceDI+IeROXvKDnw+OgZ4bCRnU8ibUfh0DTmblRv3LeVGpOtYI9rZ5ekNLQy7giSuVZeG+eSLSWws+t5SLh+aLtgE+RYA12bxQZt6h9WHNLTve3JUrd4DB4toadd/QDsuR/4L3Yuos8/m15k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769293220; c=relaxed/simple; bh=+mo+ER0526ROcuxo8cb1/GWj9jsAmwMfYjpTIQHiKKQ=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Jwe8M2Ydf50lgA2GTmjT+AqH09WvXTuNWuIIYmuczP3f2GkQJy8ntd4y8M0t0rke6fr4rU4L6gZndLLifkok/FdEM9BPezj9wzbE4Ka8N7PK6UCwEkOnwT10GF7lGEMxqzoYKaR5ZbxxOQ+T6yjbPTOcEWGtiWDX/cr/MHwc93M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MumsFYbX; 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="MumsFYbX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 108F8C116D0; Sat, 24 Jan 2026 22:20:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769293220; bh=+mo+ER0526ROcuxo8cb1/GWj9jsAmwMfYjpTIQHiKKQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=MumsFYbXI5+66boHiKTT0n1FXMpLRh5ddgy+IOpLqjZP1Whk4vLSkh19A4JeURRiG aeWPCXu71PvfV6juXUsQ/iygexm60Nn04DYU2CC+rUsSNwR3tEkCf86gPvDdloTrZ0 VFzmuhWlxP6lZF4H8qfa126k99aA/W+p1oiP/nsJMCaStzW9d9VsawYwfmqkOL+KX9 SSGQ0rU2zchTgJoYk5HrYwC0En5ZQZvEgo0Wqc0tKkH9vrVOL/1ZM/TQ1ehnOL+3hF XDn2FTRYG2GMC+YADp5ixrdJWwmrRgjVA1ajq84VduMjvtxFfnvA39I79ZD7gqOLHa zjnff4lZjCj7g== Message-ID: <7c86e2c3ec73650696579a3e03be937a8b4205a1.camel@kernel.org> Subject: Re: [PATCH 1/5] NFS: Protect against 'eof page pollution' From: Trond Myklebust To: Lorenzo Stoakes Cc: linux-nfs@vger.kernel.org Date: Sat, 24 Jan 2026 17:20:19 -0500 In-Reply-To: <4a0a8181-b0b5-4f2f-84e1-3c935273b7df@lucifer.local> References: <4a0a8181-b0b5-4f2f-84e1-3c935273b7df@lucifer.local> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.2 (3.58.2-1.fc43) Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Sat, 2026-01-24 at 21:01 +0000, Lorenzo Stoakes wrote: > On Fri, Sep 05, 2025 at 03:35:16PM -0400, Trond Myklebust wrote: > > From: Trond Myklebust > >=20 > > This commit fixes the failing xfstest 'generic/363'. > >=20 > > When the user mmaps() an area that extends beyond the end of file, > > and > > proceeds to write data into the folio that straddles that eof, > > we're > > required to discard that folio data if the user calls some function > > that > > extends the file length. > >=20 > > Signed-off-by: Trond Myklebust >=20 > Hi Trond, >=20 > Sorry to dig up an old patch but I wanted to ask about this change: >=20 > > --- > > =C2=A0fs/nfs/file.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 33 ++++++++++++++++= +++++++++++++++++ > > =C2=A0fs/nfs/inode.c=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 9 +++++++-- > > =C2=A0fs/nfs/internal.h=C2=A0 |=C2=A0 2 ++ > > =C2=A0fs/nfs/nfs42proc.c | 14 +++++++++++--- > > =C2=A0fs/nfs/nfstrace.h=C2=A0 |=C2=A0 1 + > > =C2=A05 files changed, 54 insertions(+), 5 deletions(-) > >=20 > > diff --git a/fs/nfs/file.c b/fs/nfs/file.c > > index 86e36c630f09..af2fdbfcbbf6 100644 > > --- a/fs/nfs/file.c > > +++ b/fs/nfs/file.c > > @@ -28,6 +28,7 @@ > > =C2=A0#include > > =C2=A0#include > > =C2=A0#include > > +#include > > =C2=A0#include > > =C2=A0#include > >=20 > > @@ -280,6 +281,37 @@ nfs_file_fsync(struct file *file, loff_t > > start, loff_t end, int datasync) > > =C2=A0} > > =C2=A0EXPORT_SYMBOL_GPL(nfs_file_fsync); > >=20 > > +void nfs_truncate_last_folio(struct address_space *mapping, loff_t > > from, > > + =C2=A0=C2=A0=C2=A0=C2=A0 loff_t to) >=20 > So this seems to be a slightly adjusted version of > pagecache_isize_extend(), > what was it about that that didn't work for you? >=20 > It seems the main differences are - block size alignment (surely you > still need > that though?) switching folio_test_dirty() for folio_test_uptodate() > (I'm not > sure about this change though?) and adding the trace line. 1. NFS is not a block protocol. Reads and writes are byte aligned. 2. The test for bsize >=3D PAGE_SIZE is nonsense for a byte aligned filesystem. 3. NFS does care about using folio_mkclean() to fix races between an application that is writing to the folio, and any zeroing of the data that may result from the file truncation. 4. The existing folio dirty state isn't of interest here, since NFS won't extend existing writes to cover the part of the folio that lies after the old eof. 5. The folio uptodate state is of interest, since any future pagecache read needs to see zeroed bytes starting at the old eof and extending either to the offset at the end of the folio, or to the new eof (whichever of the two is smaller). --=20 Trond Myklebust Linux NFS client maintainer, Hammerspace trondmy@kernel.org, trond.myklebust@hammerspace.com