Re: Fixing private mappings

[ebiederm+eric@npwt.net (Eric W. Biederman)]

>>>>> "BL" == Benjamin C R LaHaise <blah@kvack.org> writes:

BL> On 23 Apr 1998, Eric W. Biederman wrote:
>> Please excuse me for thinking out loud but private mappings seems to be
>> a hard problem that has not been correctly implemented in the linux
>> kernel.
>> 
>> Definition of Private Mappings:
>> A private mapping is a copy-on-write mapping of a file.  
>> 
>> That is if the file is written to after the mapping is established,
>> the contents of the mapping will always remain what the contents of
>> the file was at the time of the private mapping.

BL> No, this is not the case.  Examine the behaviour of other unicies out
BL> there that implement mmap.  The following is quoted from the man page for
BL> mmap on Solaris:

BL>      MAP_SHARED and MAP_PRIVATE describe the disposition of write
BL>      references  to  the  memory object.  If MAP_SHARED is speci-
BL>      fied, write references will change the  memory  object.   If
BL>      MAP_PRIVATE  is  specified, the initial write reference will
BL>      create a private copy of the memory object page and redirect
BL>      the  mapping  to  the copy. Either MAP_SHARED or MAP_PRIVATE
BL>      must be specified,  but  not  both.   The  mapping  type  is
BL>      retained across a fork(2).

BL> Note: 'the initial write reference will create a private copy' -- not
BL> the act of reading or mapping.

Right.  That is probably the only reasonable way to implement it.

I stated it as I did so what happens if another process writes to the
file is clear.  Another process writing to the file will be the
`initial write reference'.

So logically MAP_PRIVATE gives you a snapshot of the contents of a
file.   Not that it actually takes that snapshot...

Possibly I'm failing to see the difference in the definitions?

Was it the always remains the same bit?  I was thinking of what the
contents of the mapping would be if you don't write to it.

>> Further if another private mapping is established after one
>> private mapping has been established it should have the file contents
>> of the file at the time the mapping is established.  Not at the time
>> any previous private mapping was established.

BL> Linux does behave this way currently.

Only most of the time.

With private mappings at 1k alignment.  I have written a program
on 2.0.32 and verified this.  I don't believe the code has
significantly changed since then.

The problem is update_vm_cache only looks currently for the primary
inode page.  The one at (offset%PAGE_SIZE)==0.  So the other page at
offset%PAGE_SIZE==1k is not updated.

BL> This would be the appropriate thing to do if you'd like see such exotic
BL> behaviour ;-)
I guess everyone seems to like this :)

Eric