Subject: re: Bug in mmap() for files with holes
To: None <tls@rek.tjls.com>
From: matthew green <mrg@eterna.com.au>
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
   me.
   
   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.


.mrg.