set_pte() is no longer atomic with PAE36.

set_pte() is no longer atomic with PAE36.

[Stephen C. Tweedie]

Hi,

Ingo, do we not have a bit of a problem with set_pte() on PAE36-enabled
builds now?

	#define set_pte(pteptr, pteval) ((*(pteptr)) = (pteval))

would seem to be a problem: the 64-bit write is not atomic.  When
setting an unused pte, we want the word containing the page present bit
to be the last word written.  When clearing a pte, though, we need the
page present bit to be cleared before we invalidate the high order word,
otherwise we're in trouble if another cpu populates its tlb whilte the
pte is in an inconsistent (but valid, to the cpu) state.

Modifying an existing pte (eg. for COW) is probably even harder: do we
need to clear the page-present bit while we modify the high word?
Simply setting the dirty or accessed bits should pose no such problem,
but relocating a page looks as if it could bite here.

Basically, as long as we can assume that another cpu will only ever see
a pte with the page-present bit clear or a completely valid pte, all
should be fine.  Or have I missed something fundamental?

--Stephen

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

Re: set_pte() is no longer atomic with PAE36.

[Alan Cox]

> Modifying an existing pte (eg. for COW) is probably even harder: do we
> need to clear the page-present bit while we modify the high word?
> Simply setting the dirty or accessed bits should pose no such problem,
> but relocating a page looks as if it could bite here.

You can do 64bit atomic sets with lock cmpxchg8. It might just be slow though

> 

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

Re: set_pte() is no longer atomic with PAE36.

[Ingo Molnar]

On Thu, 2 Dec 1999, Alan Cox wrote:

> > Modifying an existing pte (eg. for COW) is probably even harder: do we
> > need to clear the page-present bit while we modify the high word?
> > Simply setting the dirty or accessed bits should pose no such problem,
> > but relocating a page looks as if it could bite here.
> 
> You can do 64bit atomic sets with lock cmpxchg8. It might just be slow though

unmaps are not fast anyway (i mean we are not counting cycles there), and
this is absolutely needed for correctness. First correctness then speed. 
Last i timed cmpxchg8b it wasnt that terribly slow - it had the slowness
of LOCK-ed instructions, but nothing dramatic. 

-- mingo


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

Re: set_pte() is no longer atomic with PAE36.

[Ingo Molnar]

On Thu, 2 Dec 1999, Stephen C. Tweedie wrote:

> Ingo, do we not have a bit of a problem with set_pte() on PAE36-enabled
> builds now?
> 
> 	#define set_pte(pteptr, pteval) ((*(pteptr)) = (pteval))

hm, looks like we'll have to use cmpxchg8b.

> would seem to be a problem: the 64-bit write is not atomic.  When
> setting an unused pte, we want the word containing the page present bit
> to be the last word written.  When clearing a pte, though, we need the
> page present bit to be cleared before we invalidate the high order word,
> otherwise we're in trouble if another cpu populates its tlb whilte the
> pte is in an inconsistent (but valid, to the cpu) state.

yep, right. if you change the PAE clear_pte() to use cmpxchg8b, does it
fix the boot problems you see?

> Modifying an existing pte (eg. for COW) is probably even harder: do we
> need to clear the page-present bit while we modify the high word?
> Simply setting the dirty or accessed bits should pose no such problem,
> but relocating a page looks as if it could bite here.
> 
> Basically, as long as we can assume that another cpu will only ever see
> a pte with the page-present bit clear or a completely valid pte, all
> should be fine.  Or have I missed something fundamental?

i think we should definitely update 64-bit ptes atomically, this could be
especially important for multiple threads mapping/unmapping areas and
building TLBs. This could also be a security risk. (just imagine half of
the pte being seen on one CPU and the TLB goes to the wrong place.)

i think we still have some other problem, but this is a definitive bug i
believe, yes.

	Ingo

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