Messages in this thread | | | Date | Tue, 25 May 2004 15:09:33 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [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/
| |