From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <DCEDB8BB-8D10-4E17-9C27-AE48718CB82F@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_8DFD1D9F-16F3-4D17-914C-8298AD90A8D5";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [PATCH 0/5] Fix a minor POSIX conformance problem
Date:   Thu, 2 Feb 2023 16:08:49 -0700
In-Reply-To: <20230202204428.3267832-1-willy@infradead.org>
Cc:     linux-fsdevel@vger.kernel.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
To:     "Matthew Wilcox (Oracle)" <willy@infradead.org>
References: <20230202204428.3267832-1-willy@infradead.org>
Precedence: bulk


--Apple-Mail=_8DFD1D9F-16F3-4D17-914C-8298AD90A8D5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 2, 2023, at 1:44 PM, Matthew Wilcox (Oracle) =
<willy@infradead.org> wrote:
>=20
> 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.

Is it possible to have mmap return SIGBUS for the writes beyond EOF?
On the one hand, that might indicate incorrect behavior of the =
application,
and on the other hand, it seems possible that the application doesn't
know it is writing beyond EOF and expects that data to be read back OK?

What happens if it is writing beyond EOF, but the block hasn't even been
allocated because PAGE_SIZE > blocksize?

IMHO, this seems better to stop the root of the problem (mmap() allowing
bad writes), rather than trying to fix it after the fact.

Cheers, Andreas

> 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
>=20
> 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
>=20
> 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(-)
>=20
> --
> 2.35.1
>=20


Cheers, Andreas


--Apple-Mail=_8DFD1D9F-16F3-4D17-914C-8298AD90A8D5
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmPcQoIACgkQcqXauRfM
H+CNdBAAhriBgXO1g+TzG5HbJSljgcpvSaRMy+yNpMbCc6Fp/C3J3xQPJReOJDee
5YOaqYEwU2ap/xwIjl+OtXpEy/zq8qwO9LCofufBtMH4akhS26i8lfWoXzeo8MzH
+ibRkNMk7vamH8PT46gwMLNldqk5pt7Dxwu/XarWsDg98JxZVQvvmPJIcXtgsETA
GLFrhm+SudzQVCeBGJS0I4ZU4eDNpJxiExlCpkR04wgHE3GvvQT2ehVjcQXasqwg
z2u9r0VwflncAmvkgIpylxOXmSX44jwpnahJwk3dAP/DmdYRf3kQVooglndm5sAF
aAj6kT/mVNKdg+GJSIHjnTJjCM7BFkyFxi06xKVWjSpfYvgA5PoY8egV20kHpA3i
wRbxnoS3u5fxEx1KHj3HVnn7vhBnRsSC3AnZjLlTvtuqp7xKNMt5S5JnADLGZ6Ud
wNrl27/8LceOvSG7E/9yOmzLUvbrzZoWSRRYIymwF/6H5g0Ki4voGImZ0l+Yn4OW
sbgwcyJ1pq5Py4PgKY+iBPK61Gtk+sTOsfC3I2KWUy+7mAfQ23pfGMjY3EUNB5eC
EXuEnYw1ePIXt2MSN9yPJLz5r882eLrdbkp0nD1jx85OJFFgJvlcZ0rmPyGpBrT7
ZPq3/kKDUTwYJXO4cW+EuNV1rcTu2YttzPLBWzECgMhmXpdz0vI=
=TgpS
-----END PGP SIGNATURE-----

--Apple-Mail=_8DFD1D9F-16F3-4D17-914C-8298AD90A8D5--