linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: nfortino@nvidia.com (Nickolas Fortino)
To: linux-arm-kernel@lists.infradead.org
Subject: preempted dup_mm misses TLB invalidate
Date: Wed, 17 Jul 2013 14:03:34 -0700	[thread overview]
Message-ID: <51E706A6.4040309@nvidia.com> (raw)
In-Reply-To: <20130717203409.GU24642@n2100.arm.linux.org.uk>

On 7/17/2013 1:34 PM, Russell King - ARM Linux wrote:
> Even if you stopped all threads on entry to a fork, the same problem
> exists - at the point that you stopped the other threads, how do you know
> what data they've written to memory?
>
> What I'm pointing out here is that in this situation, the data visible to
> the child process is unpredictable.

I agree the data visible to the child process is inherently 
unpredictable. If you stop all process threads on a fork, however, you 
do preserve the invariant that memory accesses are not seen out of 
order. In your memcopy case, it is indeterminate how much of the memcopy 
has completed, but it is known that later pages in the memcopy will only 
have been written if prior pages have been updated.

With the current kernel configuration, you can have holes. Any page 
which hits in the TLB has the memcopy data appear in the forked process. 
Any page which misses in the TLB will not appear in the forked process. 
The choice of which pages get memcopy data in the forked process will 
appear random based on TLB contents, a behavior you cannot have if you 
freeze threads on a fork.

  reply	other threads:[~2013-07-17 21:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-15 18:19 preempted dup_mm misses TLB invalidate Nickolas Fortino
2013-07-17 19:27 ` Catalin Marinas
2013-07-17 19:52   ` Stephen Warren
2013-07-17 20:01     ` Russell King - ARM Linux
2013-07-17 20:11       ` Stephen Warren
2013-07-17 20:09     ` Nickolas Fortino
2013-07-17 20:34       ` Russell King - ARM Linux
2013-07-17 21:03         ` Nickolas Fortino [this message]
2013-07-17 21:21           ` Russell King - ARM Linux
2013-07-18  1:48             ` Nickolas Fortino

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=51E706A6.4040309@nvidia.com \
    --to=nfortino@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).