Subject: Re: Bug in mmap() for files with holes
To: Thor Lancelot Simon <firstname.lastname@example.org>
From: Bill Stouder-Studenmund <email@example.com>
Date: 11/14/2007 14:50:43
Content-Type: text/plain; charset=us-ascii
On Wed, Nov 14, 2007 at 05:34:04PM -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 14, 2007 at 02:21:45PM -0800, Bill Stouder-Studenmund wrote:
> > On Wed, Nov 14, 2007 at 04:57:16PM -0500, Thor Lancelot Simon wrote:
> > > Lots of operating systems, over the years, have had bugs in mmap() su=
> > > that, for example, writing a byte into a page notionally backed by a
> > > file that has a hole in it causes a segfault or bus error.
> > >=20
> > > We appear to have such a bug for _reading_ files consisting only of h=
> > > see the program below. Modifying the program to write one byte to the
> > > file before the lseek() that extends it causes the segfault to go awa=
> > Where do you explicitly grow the file? lseek() alone won't change the f=
> > length. It is legal to lseek() past EOF.
> Hm. Yeah, and if I throw a read() in back to the lseek to 0, it does
> indeed return 0 bytes: EOF.
> > I think what you want to throw in is an ftruncate().
> Probably so. Our mmap() page is not sufficiently precise, and I don't
> have the posix realtime spec -- that's where it's specified, right? -- so
> I don't know if mmap() is supposed to succeed, but accesses then fault,
> when the mapping goes past the current EOF. Is that how it is supposed
> to work?
It's how I'd expect it to work (fail when accessing), but I'm not sure=20
what standards say. Among other things, you could map, grow then file,=20
then the pages should work. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----