kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Lev Olshvang <levonshe@yandex.com>
Cc: linux-il <linux-il@cs.huji.ac.il>,
	kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: What will happen if 2 processes map same physical page
Date: Wed, 20 Mar 2019 13:07:55 -0400	[thread overview]
Message-ID: <16760.1553101675@turing-police> (raw)
In-Reply-To: <6967041553089359@myt2-66bcb87429e6.qloud-c.yandex.net>

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.


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2019-03-20 17:08 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 [this message]
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

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=16760.1553101675@turing-police \
    --to=valdis.kletnieks@vt.edu \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=levonshe@yandex.com \
    --cc=linux-il@cs.huji.ac.il \
    /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).