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 Wed, 26 May 2004, Benjamin Herrenschmidt wrote:
>
> Well, just setting one of those 2 bits doesn't require a hash table
> invalidate as long as nothing else changes.

I'm starting to doubt this, because:

> We do dirty by mapping r/o in the hash table, and accessed on hash
> faults (our clear_young triggers a flush). So just setting those bits
> in the linux PTE without touching the hash table is fine, we'll just
> possibly take an extra fault on the next write or access, but that
> might not be much slower than going to the hash update the permissions
> directly.

But if we don't update the hash tables, how will the TLB entry _ever_ say
that the page is writable? So we won't take just _one_ extra fault on the
next write, we'll _keep_ taking them, since the hash tables will continue
to claim that the page is read-only, even if the linux sw page tables say
it is writable.

So I think the code needs to invalidate the hash after having updated the
pte. No?

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    [W:0.101 / U:1.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site