From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Lev Olshvang <levonshe@yandex.com>
Cc: linux-il <linux-il@cs.huji.ac.il>,
Okash Khawaja <okash.khawaja@gmail.com>,
kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: What will happen if 2 processes map same physical page
Date: Fri, 22 Mar 2019 19:19:12 -0400 [thread overview]
Message-ID: <25010.1553296752@turing-police> (raw)
In-Reply-To: <2235291553246149@sas1-0a6c2e2b59d7.qloud-c.yandex.net>
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.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
prev parent reply other threads:[~2019-03-22 23:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 13:42 What will happen if 2 processes map same physical page Lev Olshvang
2019-03-20 17:07 ` Valdis Klētnieks
2019-03-21 9:56 ` Lev Olshvang
2019-03-21 10:45 ` Okash Khawaja
2019-03-22 9:15 ` Lev Olshvang
2019-03-22 9:59 ` Okash Khawaja
2019-03-22 23:19 ` Valdis Klētnieks [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25010.1553296752@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=kernelnewbies@kernelnewbies.org \
--cc=levonshe@yandex.com \
--cc=linux-il@cs.huji.ac.il \
--cc=okash.khawaja@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).