lkml.org 
[lkml]   [2000]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.607 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site