Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE

["David S. Miller" <davem@redhat.com>]

On Tue, 25 May 2004 11:05:09 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:

> On Tue, 25 May 2004, David S. Miller wrote:
> > So on sparc32 sun4m we'd implement ptep_update_dirty_accessed() with
> > some kind of loop using the swap instruction?
> 
> Yes. Except that if everybody else uses atomic updates (including the hw 
> walkers), _and_ "dirty" is true, then you can optimize that case to just 
> to an atomic write (since we don't care what the previous contents were, 
> and everybody else is guaranteed to honor the fact that we set all the 
> bits.
> 
> (And an independent optimization is obviously to not do the store at all
> if it is already has the new value, although that _should_ be the rare 
> case, since if that was true I don't see why you got a page fault in the 
> first place).
> 
> So _if_ such an atomic loop is fundamentally expensive for some reason, it 
> should be perfectly ok to do
> 
> 	if (dirty) {
> 		one atomic write with all the bits set;
> 	} else {
> 		cmpxchg until successful;
> 	}

Hmmm, do you understand how broken the sparc hardware is? :-)

Seriously, the issue is that the MMU writes back access/dirty bits
asynchronously, does not do a relookup when it writes these bits back
into the PTE (like x86 and others do) it actually stores away the PTE
physical address and writes into the PTE using that, and finally as
previously mentioned we lack a cmpxchg we only have raw SWAP.

Keith W. can verify this, he has my old SuperSPARC manual which explains
all of this stuff.  Keith you might want to quote that little "atomic PTE
update sequence" piece of code that's in the manual for Linus.

--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>