[PATCH 0/5] Fix a minor POSIX conformance problem

Matthew Wilcox (Oracle) willy at infradead.org
Thu Feb 2 12:44:22 PST 2023


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




More information about the linux-afs mailing list