mmap: effect of other processes writing to a file previously mapped read-only

Question

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?

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 '19 at 07:19
@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 '19 at 07:42

score 5 · Accepted Answer · answered May 19 '19 at 23:44

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 '19 at 00:04
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](https://yarchive.net/comp/linux/map_copy.html). — , May 20 '19 at 00:18

mmap: effect of other processes writing to a file previously mapped read-only

1 Answers1