nitpicky questions regarding mmap() and msync()

nitpicky questions regarding mmap() and msync()

[Chris Friesen]

A couple questions about mmap()'d files.

1) If I have an mmap()'d file and I write to it and then I am hit with a SIGKILL
before I have a chance to msync(), am I guaranteed that changes I've made to the
information in the file will be available if I restart and try to mmap() the
same file?  The man page says only that there is no guarantee that changes are
written back to disk if msync() is not called, but some informal testing seems
to indicate that changes are in fact written out.  Is this a timing issue or
does the system guarantee this?

2) If I make changes to the contents of an mmap()'d file, am I guaranteed that
the order I make the changes is the same order that they will be available to
another process that has mmap()'d the same file?  (Or can I be bit by
optimization reordering?  If this is the case, can I get around this by reading
it as volatile and using the barrier() macro?)

The basic idea is that I have a state file stored in ramdisk in which I keep
track of some system state variables.   This gets mmap()'d into memory.  If my
process gets killed for whatever reason it can restart and read this file to
check the state.  One of the variables in this file is a flag that says whether
or not its a valid file.  If the file is invalid then more drastic recovery
measures must be taken. I want to be sure that if I clear the flag before doing
any multi-stage operations and then set it after I'm done, I can always
guarantee that if that variable is set then the contents are valid.  I would
also like to avoid calling msync() after every change if I can avoid it.

Anyone know the definitive answers to these questions?  I don't need posix
standard behaviour, just what linux currently does (and is likely to do in the
future, if it is different).

Thanks,

Chris

Re: nitpicky questions regarding mmap() and msync()

[Andi Kleen]

In article <3B732DAE.CD117CBA@sympatico.ca>,
chris_friesen@sympatico.ca (Chris Friesen) writes:
> A couple questions about mmap()'d files.
> 1) If I have an mmap()'d file and I write to it and then I am hit with a SIGKILL
> before I have a chance to msync(), am I guaranteed that changes I've made to the
> information in the file will be available if I restart and try to mmap() the
> same file?  The man page says only that there is no guarantee that changes are
> written back to disk if msync() is not called, but some informal testing seems
> to indicate that changes are in fact written out.  Is this a timing issue or
> does the system guarantee this?

The system does guarantee it. There is no special case for SIGKILL exit,
it is just an ordinary exit and it does properly munmap all your mappings.

> 2) If I make changes to the contents of an mmap()'d file, am I guaranteed that
> the order I make the changes is the same order that they will be available to
> another process that has mmap()'d the same file?  (Or can I be bit by
> optimization reordering?  If this is the case, can I get around this by reading
> it as volatile and using the barrie() macro?)

When two processes access the same mapping in Linux they always work 
on the same block of memory, so standard memory ordering rules apply.
On a lot of architectures that means you need to use appropiate read and
write barriers to avoid reordering on SMP systems.

[on some architectures like early mips chips there can be nasty issues
with virtual cache aliases though, but that should not concern you here]

The memory can be flushed to disk and reread at any time, in this 
regard it is no different from any other anonymous memory, except that 
it is not written to swap but to your backing file.

The order in which the changes are flushed to disk is completely undefined.


-Andi