Thread (57 messages) 57 messages, 7 authors, 2004-05-27

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

From: Linus Torvalds <torvalds@osdl.org>
Date: 2004-05-25 18:05:46
Also in: linux-mm, lkml

Possibly related (same subject, not in this thread)


On Tue, 25 May 2004, David S. Miller wrote:
On Tue, 25 May 2004 10:49:21 -0700 (PDT)
Linus Torvalds [off-list ref] wrote:
quoted
So what I can tell, the fix is really something like this (this does both 
x86 and ppc64 just to show how two different approaches would handle it, 
but I have literally _tested_ neither).

What do people think?
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;
	}

Oh - btw - my suggested patch was totally broken for ppc64, because that 
"ptep_update_dirty_accessed()" thing obviously also needs to that damn 
hpte_update() crud etc. 

BenH - I'm leaving that ppc64 code to somebody knows what the hell he is
doing. Ie you or Anton or something. Ok? I can act as a collector the
different architecture things for that "ptep_update_dirty_accessed()"
function.

		Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help