Re: x86 ptep_get_and_clear question

[Kanoj Sarcar <kanoj@google.engr.sgi.com>]

> 
> Ben LaHaise wrote:
> > > Processor 2 has recently done some writes, so the dirty bit is set in
> > > processor 2's TLB.
> > >
> > > Processor 1 clears the dirty bit atomically.
> > >
> > > Processor 2 does some more writes, and does not check the page table
> > > because the page is already dirty in its TLB.
> > >
> > > Result: The later writes on processor 2 do not mark the page dirty.
> > 
> > Yeah, but the tlb is flushed in those cases (look for flush_tlb_page in
> > try_to_swap_out).
> 
> As long as processor 1 waits for the flush on processor 2 to complete
> before marking the struct page dirty, that looks fine to me.
> 
> -- Jamie
> 

Since this seems to be so hard to understand, lets keep things simple and
continue with my previous example, instead of pulling new examples.

Look in mm/mprotect.c. Look at the call sequence change_protection() -> ...
change_pte_range(). Specifically at the sequence:

	entry = ptep_get_and_clear(pte);
	set_pte(pte, pte_modify(entry, newprot));

Go ahead and pull your x86 specs, and prove to me that between the 
ptep_get_and_clear(), which zeroes out the pte (specifically, when the 
dirty bit is not set), processor 2 can not come in and set the dirty 
bit on the in-memory pte. Which immediately gets overwritten by the 
set_pte(). For an example of how this can happen, look at my previous 
postings.

Jamie's example misses the point in the sense that at the very beginning,
when he says "Processor 2 has recently done some writes", processor 2 has
made sure that the dirty bit is set in the in-memory pte. So, although 
processor 1 clears the entire pte, the set_pte() will set the dirty bit,
and no information is lost. Even if processor 2 tries writing between
the ptep_get_and_clear() and set_pte(). Whether Jamie was trying to 
illustrate a different problem, I am not sure. All I am trying to say
is that the "dirty bit lost on smp x86" still exists, ptep_get_and_clear
does not do anything to fix it.

Kanoj
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/