Hi Vaaldis, Thanks for answer, I still wondering whether the kernel will allow write to a read-only page of shared library while it has mapped to several processes? Kernel knows that page's reference count >1, will it allow mmap/mprotect to change page protection ? Or will it allow direct right by physical address? I suppose that CPU should raise page fault when write is made to read only page, What is the sequence CPU raises page faul before write to page of after data is written Will CPU wait until kernel will consider what to do , whether agree and change PTE "writable " bit to 1 ? Or kernel may disagree and raise SEGFAULT? I checked in the handle_mm_fault() calls for arch_vma_access_permitted() which just returns true on most architectures which is very strange and contradicts my prediction of SEFFAULT. arch_vma_access_permitted() retutus true when is sees that access is made from foreign process? https://elixir.bootlin.com/linux/latest/ident/arch_vma_access_permitted I am totally confused. What do you think ? Regards, Lev 20.03.2019, 20:08, "Valdis Klētnieks" <valdis.kletnieks@vt.edu>:
On Wed, 20 Mar 2019 16:42:39 +0300, Lev Olshvang said:
The question is it ipossiblle in Linux/MMU/TLB that 2 processes map to the same physical address?
Totally possible. That's how mmap shared memory works, and why shared libraries are possible.
Will CPU or TLB discover that second process tries to reach occupied physical page?
Well, the hardware won't discover it as a "second" process, it only knows it's processing *this* memory access.
What if first process set page permission to read and second whats to write to this page ?
Perfectly OK - the two processes have separate page table mappings, with separate permission bits. So (for example) physical page 0x17F000 is mapped to virtual address 0x2034D000 with read-only permission n process 1's page tables, and to virtual address 0x98FF3000 with read-write permission in process 2's page tables. No problem.
(And before you ask, yes it's possible for process 2 to running on one core doing a write to the page at the exact same time that process 1 is doing a read on another core. Depending on the hardware cache design, this may or may not get process 1 updated data. This is why locking and memory barriers are important. See Documentation/memory-barriers.txt for more details)
"And then there's the Alpha" - a processor design that got much of its speed by being weird about this stuff. :)
Perhaps during context switch all page access permissions of first process is flashed out from MMU ?
Actually, the kernel just points the MMU at a new set of page table entries and lets the TLB reload as needed. In particular, on most architectures, the kernel tries really hard to ensure that all processes share at least part of their page table mappings so the kernel is always mapped at the same place, meaning that there's a better chance that on a syscall, the TLB already has hot entries for large parts of the kernel so no TLB reloads are needed.