From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
To: linux-fsdevel@vger.kernel.org
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-mm@kvack.org,
Hugh Dickins <hughd@google.com>,
linux-kernel@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH 0/5] Fix a minor POSIX conformance problem
Date: Thu, 2 Feb 2023 20:44:22 +0000 [thread overview]
Message-ID: <20230202204428.3267832-1-willy@infradead.org> (raw)
POSIX requires that on ftruncate() expansion, the new bytes must read
as zeroes. If someone's mmap()ed the file and stored past EOF, for
most filesystems the bytes in that page will be not-zero. It's a
pretty minor violation; someone could race you and write to the file
between the ftruncate() call and you reading from it, but it's a bit
of a QOI violation.
I've tested xfs (passes before & after), ext4 and tmpfs (both fail
before, pass after). Testing from other FS developers appreciated.
fstest to follow; not sure how to persuade git-send-email to work on
multiple repositories
Matthew Wilcox (Oracle) (5):
truncate: Zero bytes after 'oldsize' if we're expanding the file
ext4: Zero bytes after 'oldsize' if we're expanding the file
tmpfs: Zero bytes after 'oldsize' if we're expanding the file
afs: Zero bytes after 'oldsize' if we're expanding the file
btrfs: Zero bytes after 'oldsize' if we're expanding the file
fs/afs/inode.c | 2 ++
fs/btrfs/inode.c | 1 +
fs/ext4/inode.c | 1 +
mm/shmem.c | 2 ++
mm/truncate.c | 7 +++++--
5 files changed, 11 insertions(+), 2 deletions(-)
--
2.35.1
next reply other threads:[~2023-02-02 20:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-02 20:44 Matthew Wilcox (Oracle) [this message]
2023-02-02 20:44 ` [PATCH 1/5] truncate: Zero bytes after 'oldsize' if we're expanding the file Matthew Wilcox (Oracle)
2023-02-03 13:00 ` Brian Foster
2023-02-03 15:07 ` Matthew Wilcox
2023-02-02 20:44 ` [PATCH 2/5] ext4: " Matthew Wilcox (Oracle)
2023-02-02 20:44 ` [PATCH 3/5] tmpfs: " Matthew Wilcox (Oracle)
2023-02-02 20:44 ` [PATCH 4/5] afs: " Matthew Wilcox (Oracle)
2023-02-02 20:44 ` [PATCH 5/5] btrfs: " Matthew Wilcox (Oracle)
2023-02-02 20:44 ` [PATCH 6/5] generic: test ftruncate zeroes bytes after EOF Matthew Wilcox (Oracle)
2023-02-03 11:57 ` Johannes Thumshirn
2023-02-03 13:13 ` Matthew Wilcox
2023-02-03 16:35 ` Darrick J. Wong
2023-02-02 23:08 ` [PATCH 0/5] Fix a minor POSIX conformance problem Andreas Dilger
2023-02-03 13:21 ` Matthew Wilcox
2023-02-03 16:23 ` David Laight
2023-02-03 16:29 ` Matthew Wilcox
2023-02-27 13:49 ` [PATCH 4/5] afs: Zero bytes after 'oldsize' if we're expanding the file David Howells
2023-02-27 14:09 ` Matthew Wilcox
2023-02-27 14:20 ` David Howells
2023-02-27 14:49 ` David Howells
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=20230202204428.3267832-1-willy@infradead.org \
--to=willy@infradead.org \
--cc=fstests@vger.kernel.org \
--cc=hughd@google.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.