Re: threads and fork on machine with VIPT-WB cache

[NIIBE Yutaka <gniibe@fsij.org>]

Thanks a lot for the discussion.

James Bottomley wrote:
> So your theory is that the data the kernel sees doing the page copy can
> be stale because of dirty cache lines in userspace (which is certainly
> possible in the ordinary way)?

Yes.

> By design that shouldn't happen: the idea behind COW breaking is
> that before it breaks, the page is read only ... this means that
> processes can have clean cache copies of it, but never dirty cache
> copies (because writes are forbidden).

That must be design, I agree.

To keep this condition (no dirty cache for COW page), we need to flush
cache before ptep_set_wrprotect.  That's my point.

Please look at the code path:
   (kernel/fork.c)
   do_fork -> copy_process -> copy_mm -> dup_mm -> dup_mmap ->
   (mm/memory.c)
   copy_page_range -> copy_p*d_range -> copy_one_pte -> ptep_set_wrprotect

The function flush_cache_dup_mm is called from dup_mmap, that's enough
for a case of a process with single thread.

I think that:
We need to flush cache before ptep_set_wrprotect for a process with
multiple threads.  Other threads may change memory after a thread
invokes do_fork and before calling ptep_set_wrprotect.  Specifically,
a process may sleep at pte_alloc function to get a page.
--