[Pkg-gauche-devel] threads and fork on machine with VIPT-WB cache
NIIBE Yutaka
gniibe at fsij.org
Mon Apr 5 00:39:09 UTC 2010
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.
--
More information about the Pkg-gauche-devel
mailing list