[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fixing private mappings
>>>>> "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