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.
next prev parent 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).