Are multiple MAP_PRIVATE mappings of the same file, in the same process, still private?

Question

Linux mmap(2) says:

MAP_PRIVATE Create a private copy-on-write mapping. Updates to the mapping are not visible to other processes mapping the same file, and are not carried through to the underlying file. It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region.

I'm specifically asking about this part: "not visible to other processes mapping the same file"

But what about other mappings of the same file in this process?

I understand that "changes ... are not carried through to the underlying file", but that doesn't clearly indicate whether or not those changes affect other mappings of the same file.

The following related questions do not answer this:

• Query on MAP_PRIVATE
• Writing to MAP_PRIVATE mmaped file
• difference between MAP_PRIVATE and MAP_SHARED in mmap for threads

Nate Eldredge pointed out that the POSIX mmap spec also does not specify this behavior, stating only:

If MAP_PRIVATE is specified, modifications to the mapped data by the calling process shall be visible only to the calling process and shall not change the underlying object.

Cope

In my test on Ubuntu 20.04 x86-64, MAP_PRIVATE mappings in the same process don't update each other. – Es

It's interesting that POSIX doesn't seem to specify behavior in this case either: pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html – Es

My test also shows that the mappings are private w.r.t. each other (which is what I would expect). – Cope

In the absence of clarity in the specification, what makes the most sense? It is not hard to imagine a process given two files to process, which it maps and uses, unaware they are the same. In this case, the mappings should be separate, or it would appear to the processing algorithm that unexpected changes are occurring. For the alternative, when would we want to knowingly map a file twice and have the changes appear in both locations? That seems like a waste of address space, and anything that can be done with that can be done without it. So implementors ought to choose the former. – Baroness

@EricPostpischil: Conceivably one could argue for a difference depending on whether the mappings used the same fd, or two different fds open on the same file. – Es

@NateEldredge: Not fds but open file descriptions. Two fds to the same open file description can't be distinct in such a context. – Pl

@R..GitHubSTOPHELPINGICE: I see, as in whether the two fds were obtained from two calls to open() (two separate file descriptions), or whether one was from open() and the other from dup() (one file description, two file descriptors). – Es

I agree that the determined behavior (MAP_PRIVATE always makes a 100% private mapping, regardless of process, file, or fd) makes sense. However, empirically testing against one kernel isn't exactly a safe way to write software. This seems to be a huge gap in the documentation. – Cope

Well, for Linux at least, you can submit a documentation bug. And one could probably verify from reading the kernel source that this is the behavior and always has been. For POSIX, perhaps a defect report is in order. – Es

Answer 1

I think

shall not change the underlying object

makes the intent clear. When you mmap the same underlying object again in the same process, you're again making a map of the underlying object, the contents of which are determined by the content of that underlying object.

Admittedly it could/should be more clear.

Pl