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

[Benjamin Herrenschmidt]

> 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.

Well, just setting one of those 2 bits doesn't require a hash table
invalidate as long as nothing else changes.

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

The original problem I have with set_pte is that our current
implementation of set_pte will overwrite the entire PTE, possibly losing
the bits that indicate that there is a copy in the hash and its index in
the hash bucket. So if set_pte is called on a PTE that is present, we
must flush it properly first as we will lose track of the hash one when
overriding. hpte_update() will simply add the old PTE to a batch which
is then flushed by either the mmu gather batch end, or by a call to
flush_tlb_*  

Ben.


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