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
Message-Id: <20230202204428.3267832-1-willy@infradead.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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