preempted dup_mm misses TLB invalidate

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Wed, Jul 17, 2013 at 02:03:34PM -0700, Nickolas Fortino wrote:
> 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.

So... how is this handled on x86 or any of the other architectures?  I'm
willing to bet that the behaviour you observe on ARM is inherently visible
on many of the other Linux architectures.

Short of modifying the generic kernel to halt all threads, this can not be
fixed.