Subject: re: Bug in mmap() for files with holes
To: None <>
From: matthew green <>
List: tech-kern
Date: 11/15/2007 10:23:33
   On Wed, Nov 14, 2007 at 05:34:04PM -0500, Thor Lancelot Simon wrote:
   > > 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?
   Actually, there's a difference in behavior here that still really bothers
   If I write one byte of 0 *at offset 0* then lseek to 1024, then mmap the
   file with a length of 1024, memory-reads from the entire mapping return 0.
   If I just create the file and do the lseek, memory-reads from any part of
   the mapping cause a SEGV.
   This seems wrong.

what do you expect?  this is what i would expect.