From: Jimmy Zuber <jamz@amazon.com>
To: Miklos Szeredi <miklos@szeredi.hu>, Shuah Khan <shuah@kernel.org>
Cc: <fuse-devel@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>
Subject: [PATCH 0/2] fuse: zero the partial EOF page when extending a file
Date: Fri, 31 Jul 2026 20:38:40 +0000 [thread overview]
Message-ID: <20260731203842.540798-1-jamz@amazon.com> (raw)
Extending a fuse file past a non-page-aligned EOF does not zero the tail of
the old last page. When that page is cached and has been mmap-dirtied
beyond the old EOF, the now in-bounds tail is served to later reads as stale
data rather than zeros, which violates POSIX file-extension semantics.
This is the same class of bug that commit b1817b18ff20 ("NFS: Protect
against 'eof page pollution'") fixed for the NFS client; fuse has the
equivalent gap on its non-writeback_cache, FOPEN_KEEP_CACHE path.
pagecache_isize_extended() cannot be reused because it is a no-op when
i_blocksize() >= PAGE_SIZE, which always holds for a non-fuseblk mount, so
patch 1 open-codes the zeroing and calls it from all three paths that extend
a file: buffered write, setattr/truncate, and fallocate. Patch 2 adds a
self-contained raw /dev/fuse selftest covering each path; every case fails
without patch 1 and passes with it.
Tested by booting the patched kernel under User-Mode Linux and running the
new selftest (4/4 pass; 4/4 fail without patch 1), and reproduced against
libfuse's passthrough_ll example daemon (-o cache=always,no_writeback).
Jimmy Zuber (2):
fuse: zero the partial EOF page when extending a file
selftests/fuse: test post-EOF page zeroing when a file is extended
fs/fuse/dir.c | 3 +
fs/fuse/file.c | 56 +++
fs/fuse/fuse_i.h | 1 +
.../selftests/filesystems/fuse/.gitignore | 1 +
.../selftests/filesystems/fuse/Makefile | 3 +
.../filesystems/fuse/write_extend_eof_test.c | 368 ++++++++++++++++++
6 files changed, 432 insertions(+)
create mode 100644 tools/testing/selftests/filesystems/fuse/write_extend_eof_test.c
base-commit: 7d87a5a284bb34edb3f4e7e312ef403b3385a7b7
--
2.50.1
next reply other threads:[~2026-07-31 20:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 20:38 Jimmy Zuber [this message]
2026-07-31 20:38 ` [PATCH 1/2] fuse: zero the partial EOF page when extending a file Jimmy Zuber
2026-07-31 20:38 ` [PATCH 2/2] selftests/fuse: test post-EOF page zeroing when a file is extended Jimmy Zuber
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=20260731203842.540798-1-jamz@amazon.com \
--to=jamz@amazon.com \
--cc=fuse-devel@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=shuah@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.