Re: failed shared mmap'ing of /dev/zero

Jeremy Fitzhardinge (jeremy@zip.com.au)
Sat, 16 Mar 1996 18:02:07 +1000


Sean Foderaro wrote:
>
> kernel: 1.3.71
>
> /dev/zero in linux refuses to do a MAP_SHARED mmap if PROT_WRITE
> is also given.
>
> Other Unixes (sunos, solaris, irix. ...) have no problem with this.
>
> It's definitely intentional that such a mapping is refused but
> it isn't clear why.

Well, what would it mean? If you did this to an ordinary file, it would
imply that all processes mmaping from the file and all reads would see
changes made through the writable shared mapping. In other words, you
change the file contents.

/dev/zero, by definition, always contains zeros: you can't change it.
There are two ways you could sensibly and consistently handle shared
write mappings: either prevent them altogether, or create a memory mapping
which you can write to, but would always read as zero.

Other unicies define some extra semantics for writable shared mappings of
/dev/zero. Perhaps it would be worth emulating them, but they would be
extentions rather than a logical result of the union of behaviours of
writable shared mmap and /dev/zero.

Personally, I've always thought it would be interesting to regard each opening
of /dev/zero as containing a separate instance of an infinite number of zeros.
That is, if you do a PROT_WRITE MAP_SHARED mmap on an fd, and pass that fd to
other processes who also mmap it, you can shared a common piece of memory with
no file backing. However, other open instances of /dev/zero wouldn't see the
changes, so the global semantics of /dev/zero are maintained. Is this what
Solaris and Irix do (I should really know the answer to this, but I've never
looked into it).

J