On Tue, 2 Aug 2005, Linus Torvalds wrote: > On Tue, 2 Aug 2005, Hugh Dickins wrote: > > > > It might not be so bad. It's going to access the struct page anyway. > > And clearing dirty from parent and child at fork time could save two > > set_page_dirtys at exit time. But I'm not sure that we could batch the > > the dirty bit clearing into one TLB flush like we do the write protection. > > Yes, good point. If the thing is still marked dirty in the TLB, some other > thread might be writing to the page after we've cleared dirty but before > we've flushed the TLB - causing the new dirty bit to be lost. I think.
Would that matter? Yes, if vmscan sneaked in at some point while page_table_lock is dropped, and wrote away the page with the earlier data. But I was worrying about the reverse case, that we clear dirty, then another thread sets it again before we emerge from copy_page_range, so it gets left behind granting get_user_pages write permission. Hmm, that implies that the other thread doesn't yet see wrprotect (because we've not yet flushed TLB), which probably implies it would still see dirty set: and so not set it again, so not a possible case. But that's a precarious, processor-dependent argument: I don't think it's safe to rely on, and your reverse case is already a problem. I don't believe there's a safe efficient way we could batch clearing dirty there. We could make a second pass of the whole mm after the flush TLB has asserted the wrprotects; but that won't win friends. I'm thinking of reverting to the old __follow_page, setting write_access -1 in the get_user_pages special case (to avoid change to all the arches, in some of which write_access is a boolean, in some a bitflag, but in none -1), and in that write_access -1 case passing back the special code to say do_wp_page has done its full job. Combining your and Nick's and Andrew's ideas, and letting Martin off the hook. Or would that disgust you too much? (We could give -1 a pretty name ;) Working on it now, but my brain in an even lower power state than ever. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/