Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Thu, 24 Feb 2000 13:49:18 +0000 (GMT) | Subject | Re: mmap/munmap semantics |
| |
Hi,
On 24 Feb 2000 07:41:45 -0600, ebiederm+eric@ccr.net (Eric W. Biederman) said:
>> The system will free any whole pages in the specified >> region. All modifications will be lost and any swapped >> out pages will be discarded. Subsequent access to the >> region will result in a zero-fill-on-demand fault as >> though it is being accessed for the first time. >> Reserved swap space is not affected by this call.
> Which is fine but if it works this way on shared memory it is broken, > at least unless all mappings set (MADV_DONTNEED) and you can prove there > was no file-io. Otherwise you could loose legitimate file writes.
Not necessarily, if this behaviour is defined. It is no more broken than the fact that write() can overwrite another process's data, or truncate() can invalidate another process's mapping. This is an explicitly destructive system call and the user must have write access to the file.
The discarding of modifications is obviously correct if the mapping is MAP_PRIVATE, but I'd be interested in seeing what other Unixen actually do on MAP_SHARED maps. Similarly,
msync(MS_INVALIDATE)
is expected to discard modifications by some applications (and I've personally had requests for this funcationality from vendors whose applications use it on shared memory segments). Its definition in DU includes:
After a successful call to the msync() function with the flags parameter set to MS_INVALIDATE, all previous modifications to the file using the write() function are visible to the mapped region. Previous direct modifications to the mapped region might be lost.
Again it isn't explicit whether this applies only to MAP_PRIVATE or to MAP_SHARED too.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |