From: Paulo Alcantara <pc@manguebit.org>
To: linux-cifs@vger.kernel.org, netfs@lists.linux.dev
Cc: Christian Brauner <brauner@kernel.org>,
David Howells <dhowells@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Namjae Jeon <linkinjeon@kernel.org>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Tom Talpey <tom@talpey.com>, Bharath SM <bharathsm@microsoft.com>
Subject: [PATCH v3 00/15] netfs, cifs: data corruption fixes
Date: Wed, 30 Sep 2026 00:28:07 -0300 [thread overview]
Message-ID: <20260930032822.1835287-1-pc@manguebit.org> (raw)
This series fixes a number of data corruption and spurious I/O error
bugs found by running generic/363 (fsx) in a loop against Windows
Server 2022 and Samba 4.24 servers.
* Post-EOF pagecache poisoning on extend (1-5)
Data dirtied past EOF through an mmapped region was never discarded,
so it reappeared as file content once the file was extended by an
ordinary write, a truncate, a zero range, a copy range or a clone
range. pagecache_isize_extended() doesn't help here: it's a no-op on
cifs because i_blkbits is 14. Only the one folio straddling the old
EOF can hold such data, since pages wholly beyond EOF can't be
faulted in, so each extending path now zeroes or discards that folio.
* Missing flush or drain before trusting server or pagecache state (6-9)
FSCTL_QUERY_ALLOCATED_RANGES can report just-written data as a hole
unless it has been committed to disk first, and the O_TRUNC open,
interior zero range and server-side copy/clone paths did not flush
dirty data or drain in-flight I/O before an operation that assumes
the pagecache and the server agree on the file's contents.
* fallocate refused without a read lease (10, 12)
smb3_zero_range() and smb3_simple_falloc() returned -EOPNOTSUPP for
any size-extending request whenever the inode wasn't read caching,
since the cached i_size couldn't be trusted. Query the server's EOF
in that case instead of refusing the request outright.
* Short reads leaving stale data behind (11, 13, 14)
The read-gaps path and the DIO/unbuffered read collector left the
untransferred tail of a short read untouched, and cifs could not
tell a genuine EOF from a stale cached remote_i_size after a lease
downgrade. A read racing an extending write could come back short
and, in the read-gaps case, have that stale folio content written
back to the server.
* Unstable pages during a signed write (15)
cifs signs the pagecache folios in place before handing them to the
socket. A buffered write could modify a folio while a write
subrequest built from it was still in flight, so the signature no
longer matched the data that followed it; the server answered
STATUS_ACCESS_DENIED, which surfaced later as -EIO.
================================================================
Changes since v2:
* Patch 12: zero the stale folio against the client's local i_size
instead of the server-queried EOF, so an extending, leaseless
preallocate can't skip zeroing past the client's real EOF.
Changes since v1:
* Patch 1: split the helper into netfs_clear_stale_pre_isize()
(unexported) and netfs_clear_stale_post_isize() (exported for CIFS).
* Patch 2: capture old_size before the resize RPC and call
netfs_clear_stale_post_isize() after i_size is updated, closing a
stat() race.
* Patch 9: restore unmap_mapping_pages() before the flush/invalidate so
a concurrent mmap store can't redirty the destination folio.
* Patch 10: refuse -EOPNOTSUPP when the queried server EOF still falls
short, and re-check a fresh i_size before the final SMB2_set_eof().
* Patch 12: thread old_eof into smb3_simple_fallocate_range() so it
doesn't misjudge a range as past EOF from a stale i_size.
* Picked up Reviewed-by from Namjae Jeon on patches 3-8, 11 and 13-14.
Paulo Alcantara (15):
netfs: clear post-EOF pagecache when extending a file via write
smb: client: clear post-EOF pagecache when extending a file via
truncate
smb: client: discard post-EOF pagecache when extending a file via zero
range
smb: client: discard post-EOF pagecache when extending a file via copy
range
smb: client: discard post-EOF pagecache when extending a file via
clone range
smb: client: flush and commit data before querying allocated ranges
smb: client: drain outstanding I/O before truncating on O_TRUNC open
smb: client: flush dirty data before zeroing a range
smb: client: drain and invalidate before server-side copy/clone
smb: client: only require read lease for size-extending zero range
netfs: zero gaps in read-gaps folio to avoid writing back stale data
smb: client: only require read lease for size-extending preallocate
netfs: zero the tail of a short DIO/unbuffered read
smb: client: distinguish real EOF from a stale remote_i_size on read
smb: client: require stable pages for signed connections
Documentation/filesystems/netfs_library.rst | 26 ++++
fs/netfs/buffered_read.c | 7 ++
fs/netfs/buffered_write.c | 9 ++
fs/netfs/direct_write.c | 9 ++
fs/netfs/internal.h | 2 +
fs/netfs/misc.c | 99 +++++++++++++++
fs/netfs/read_collect.c | 24 ++++
fs/smb/client/cifsfs.c | 41 +++++-
fs/smb/client/cifsfs.h | 5 +-
fs/smb/client/file.c | 5 +-
fs/smb/client/inode.c | 24 ++--
fs/smb/client/smb2ops.c | 130 +++++++++++++++-----
fs/smb/client/smb2pdu.c | 10 +-
include/linux/netfs.h | 2 +
14 files changed, 342 insertions(+), 51 deletions(-)
--
2.55.0
next reply other threads:[~2026-09-30 3:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 3:28 Paulo Alcantara [this message]
2026-09-30 3:28 ` [PATCH v3 01/15] netfs: clear post-EOF pagecache when extending a file via write Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 02/15] smb: client: clear post-EOF pagecache when extending a file via truncate Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 03/15] smb: client: discard post-EOF pagecache when extending a file via zero range Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 04/15] smb: client: discard post-EOF pagecache when extending a file via copy range Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 05/15] smb: client: discard post-EOF pagecache when extending a file via clone range Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 06/15] smb: client: flush and commit data before querying allocated ranges Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 07/15] smb: client: drain outstanding I/O before truncating on O_TRUNC open Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 08/15] smb: client: flush dirty data before zeroing a range Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 09/15] smb: client: drain and invalidate before server-side copy/clone Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 10/15] smb: client: only require read lease for size-extending zero range Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 11/15] netfs: zero gaps in read-gaps folio to avoid writing back stale data Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 12/15] smb: client: only require read lease for size-extending preallocate Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 13/15] netfs: zero the tail of a short DIO/unbuffered read Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 14/15] smb: client: distinguish real EOF from a stale remote_i_size on read Paulo Alcantara
2026-09-30 3:28 ` [PATCH v3 15/15] smb: client: require stable pages for signed connections Paulo Alcantara
2026-09-30 15:17 ` [PATCH v3 00/15] netfs, cifs: data corruption fixes Namjae Jeon
2026-09-30 17:37 ` Paulo Alcantara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260930032822.1835287-1-pc@manguebit.org \
--to=pc@manguebit.org \
--cc=bharathsm@microsoft.com \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=netfs@lists.linux.dev \
--cc=ronniesahlberg@gmail.com \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox