4

I am trying to understand what happens when a file, which has been mapped into memory by the mmap system call, is subsequently written to by other processes.

I have mmaped memory with PROT_READ protection in "process A". If I close the underlying file descriptor in process A, and another process later writes to that file (not using mmap; just a simple redirection of stdout to the file using > in the shell), is the mmaped memory in the address space of process A affected? Given that the pages are read-only, I would expect them not to change. However, process A is being terminated by SIGBUS signals as a result of invalid memory accesses (Non-existent physical address at address 0x[...]) when trying to parse the mapped memory. I am suspecting that this is stemming from writes to the backing file by other processes. Would setting MAP_PRIVATE be sufficient to completely protect this memory from other processes?

  • 1
    Whats worse than seeing the changed content is having a changed length. It will make you fault on read access to the area behind the truncation (and the truncation might be at offset 0) – eckes May 20 at 7:19
  • 1
    @eckes : Thanks, I think that is the source of the SIGBUS signals my process received after another processed truncated the file it had mapped. – user001 May 20 at 7:42
5

If I close the underlying file descriptor in process A,

closing the file descriptor doesn't change anything at all

another process later writes to that file (not using mmap; just a simple redirection of stdout to the file using > in the shell), is the mmaped memory in the address space of process A affected?

It may be. The manpage of mmap(2) says:

 MAP_PRIVATE
    ...
    It is  unspecified  whether changes made to the file
    after the mmap() call are visible in the mapped region.

In practice, changes made by other processes seem to be reflected in the content of the mmaped region, at least for regular files.

However, process A is being terminated by SIGBUS signals as a result of invalid memory accesses (Non-existent physical address at address 0x[...]) when trying to parse the mapped memory.

I'm expecting that to happen when you truncate a mmaped file.

Would setting MAP_PRIVATE be sufficient to completely protect this memory from other processes?

No, MAP_PRIVATE only prevent modifications to the memory from being carried through to the backing file, not the reverse.

  • Thanks, that helps. So it sounds like mmap is not the right tool for reading (and preserving in memory) the current state of a file, when that file might be modified by other processes before the memory has been completely read by the process which created the map? – user001 May 20 at 0:04
  • 1
    hurd seems to have a MAP_COPY for that, but that's not supported on Linux/BSD/Solaris/etc. You can read more about it here. – mosvy May 20 at 0:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.