What will happen if 2 processes map same physical page

[Valdis Kl=?utf-8?Q?=c4=93?=tnieks]

On Fri, 22 Mar 2019 12:15:49 +0300, Lev Olshvang said:

> But the question might be rephrased :  IMHO Kernel should mandate same PTE
> flags no matter how many virtual mapping were made to the same physical page.

And exactly *why* should it be "mandated"?  Certainly, for many classes of objects,
such as shared libraries, it's a desirable feature (maybe - but see below).

However, there's plenty of *other* use cases where the programmer may want to
have one control process having read/write access to a memory segment, while
a bunch of worker processes are merely reading the data.

For instance, if you're serving out complicated computations to sub-processes that
involve a lot of parameters and input data, the control process already *has* all this
data (potentially megabytes of it) in memory. Using shared memory to transfer it to
the worker process is a lot more efficient than having to stuff it all through a socket.

And even for shared libraries, you may want one process to be able to write to the
space while others are reading it, for live patching and similar functions.  (Yes, there's
a security trade-off there - and yes, there are sites that will accept the risk, and no,
that sort of trade-off belongs in userspace, not in the kernel).

The kernel does mechanism, not policy.  So it's totally reasonable to have a
defined way for userspace to say "this page can only be shared with these
permissions" - that's mechanism. Having the kernel force a specific value
without a good architectural reason is policy.

(Sometimes the kernel does force things to work a specific way if it's required
to guarantee system stability.  That's why you can't use the  write() system
call on a directory even if you have write permissions - you can only use stuff
like link() and open(). Permissions on shared memory pages don't involve that
sort of kernel self-defense issue.