lkml.org 
[lkml]   [2004]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ppc64: Fix possible race with set_pte on a present PTE


On Tue, 25 May 2004, Andrea Arcangeli wrote:
>
> entry = ptep_get_and_clear(pte);
> set_pte(pte, pte_modify(entry, newprot));
>
> Again no atomic instructions.

Well, actually, that "ptep_get_and_clear()" is actually an atomic
instruction. Or at least it had _better_ be.

> I believe using ptep_establish in handle_mm_fault makes little sense,
> to make the most obvious example there's no need of flushing the tlb in
> handle_mm_fault to resolve young or dirty page faults. Not a big deal
> for x86 and x86-64 that reaches that path only if a race happens, but on
> alpha we shouldn't flush the tlb. If some weird architecture really need
> to flush the tlb they still can inside
> ptep_handle_[young|dirty]_page_fault.

Actually, especially on alpha we _do_ need to flush the TLB.

Think about it: the TLB clearly contains the right virt->physical mapping,
but the TLB contains the wrong "control bits".

If we don't flush the TLB, the TLB will _continue_ to contain the wrong
control bits.

And as you saw earlier, if those bits are wrong, you get some really nasty
behaviour, like infinite page faults. If the TLB still says that the page
is non-readable, even though _memory_ says it is readable, it doesn't much
matter that we updated the page tables correctly in memory. The CPU will
use the TLB.

So that TLB flush actually _is_ fundamental.

Arguably we could remove it from x86. On the other hand, arguably it
doesn't actually matter on x86, so..

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2011 Jasper Spaans