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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
