Matt Kraai wrote:
On Fri, Jan 27, 2006 at 04:43:16PM +0100, Daniel Schepler wrote:

Le Vendredi 27 Janvier 2006 16:14, Matt Kraai a écrit :

On Fri, Jan 27, 2006 at 11:08:48AM +0100, Daniel Schepler wrote:

I see the build is somehow succeeding on the buildd's, though... but I
don't know what's different.

Would you please compile and run the attached program on your system
and let me know what the result is?

Running kernel 2.6.15-1-686 (version 2.6.15-3) on my laptop, I got:

[EMAIL PROTECTED]:~/test$ ./mmap-test
char at 0xb7fc0000 is 0
did not fault dereferencing 0xB7FC0000

(Although I got several warnings from -Wall.)

Thanks for doing this.

Bruce, is this what you expected?

Hi Guys,

It is not what I expected, but it is not necessarily invalid.
mmap implementations are described as *trying* to map the data between
between some unmapped pages just so that you can try to extend
the mapping.  Given that this program is not doing anything else,
it really *ought* to be the case that the reference faults.  There should
be lots of unused virtual address space available.

Cheers - Bruce

P.S.  I should not always rely on Open Group docs.  I just saw this in
Linux docs:

     MAP_ANONYMOUS
          The mapping is not backed by any file; the fd and  offset  argu-
          ments  are ignored.  This flag in conjunction with MAP_SHARED is
          implemented since Linux 2.4.

which means my original version ought to have always worked, but was
not portable.  Well, now with MAP_PRIVATE, it should be portable, too.  :)

Anyway, here is some POSIX verbiage that actually implies that the above
reference really should fault (though it is colored "optional"):

   The system shall always zero-fill any partial page at the end of an object.
   Further, the system shall never write out any modified portions of the last
   page of an object which are beyond its end. [MPR] [Option Start]
>> References within the address range starting at pa and continuing for len
>> bytes to whole pages following the end of an object shall result in delivery
>> of a SIGBUS signal. [Option End]

   An implementation may generate SIGBUS signals when a reference would cause
   an error in the mapped object, such as out-of-space condition.

I suppose I could wrap the anonymous mmap call in sigbus protection, but
holy moly, just how friggin hard should it be to mmap a bloody text file
anyways?  Sheesh!!!

Reply via email to