CODEWITHSUNDEEP
memorysystemmmap
Peter
Peter

Reputation: 2320

Understanding file mapping

I try to understand mmap and got the following link to read:
http://duartes.org/gustavo/blog/post/page-cache-the-affair-between-memory-and-files

I understand the text in general and it makes sense to me. But at the end is a paragraph, which I don't really understand or it doesn't fit to my understanding.

The read-only page table entries shown above do not mean the mapping is read only, they’re merely a kernel trick to share physical memory until the last possible moment. You can see how ‘private’ is a bit of a misnomer until you remember it only applies to updates. A consequence of this design is that a virtual page that maps a file privately sees changes done to the file by other programs as long as the page has only been read from. Once copy-on-write is done, changes by others are no longer seen. This behavior is not guaranteed by the kernel, but it’s what you get in x86 and makes sense from an API perspective. By contrast, a shared mapping is simply mapped onto the page cache and that’s it. Updates are visible to other processes and end up in the disk. Finally, if the mapping above were read-only, page faults would trigger a segmentation fault instead of copy on write.

The folloing to lines doesn't match for me. I see no sense.

A consequence of this design is that a virtual page that maps a file privately sees changes done to the file by other programs as long as the page has only been read from.

It is private. So it can't see changes by others!

Finally, if the mapping above were read-only, page faults would trigger a segmentation fault instead of copy on write.

Don't know what the author means with this. Is their a flag "MAP_READ_ONLY"? Until a write occurs, every pointer from the programs virtual-pages to the page-table-entries in the page-cache is read-only.

Can you help me to understand this two lines? Thanks

Update
It seems it got it, with some help.

A consequence of this design is that a virtual page that maps a file privately sees changes done to the file by other programs as long as the page has only been read from.

Although a mapping is private, the virtual page really can see the changes by others, until it modifiy itselfs a page. The modification becomes is private and is only visible to the virtual page of the writing program.

Finally, if the mapping above were read-only, page faults would trigger a segmentation fault instead of copy on write.

I'm told that pages itself can also have permissions (read/write/execute).

Tell me if I'm wrong.

Upvotes: 0

Views: 398

Answers (1)

Celada
Celada

Reputation: 22261

This fragment:

A consequence of this design is that a virtual page that maps a file privately sees changes done to the file by other programs as long as the page has only been read from.

is telling you that the kernel cheats a little bit in the name of optimization. Even though you've asked for a private mapping, the kernel will actually give you a shared one at first. Then, if you write the page, it becomes private.

Observe that this "cheating" doesn't matter (doesn't make any difference) if all processes which are accessing the file are doing it with MAP_PRIVATE, because no actual changes to the file will ever occur in that case. Different processes' mappings will simply be upgraded from "fake cheating MAP_PRIVATE" to true "MAP_PRIVATE" at different times according to whenever each process first writes to the file. This is probably a common scenario. It's only if the file is being concurrently updated by other means (MAP_SHARED with PROT_WRITE or else regular, non-mmap I/O operations) that it makes a difference.

I'm told that pages itself can also have permissions (read/write/execute).

Sure, they can. You have to ask for the permissions you want when you initially map the file, in fact: the third argument to mmap, which will be a combination of PROT_READ, PROT_WRITE, PROT_EXEC, and PROT_NONE.

Upvotes: 1

Related Questions