c5cf0e30bf
Our MMU hash management code would not set the "C" bit (changed bit) in the hardware PTE when updating a RO PTE into a RW PTE. That would cause the hardware to possibly to a write back to the hash table to set it on the first store access, which in addition to being a performance issue, might also hit a bug when running with native hash management (non-HV) as our code is specifically optimized for the case where no write back happens. Thus there is a very small therocial window were a hash PTE can become corrupted if that HPTE has just been upgraded to read write, a store access happens on it, and that races with another processor evicting that same slot. Since eviction (caused by an almost full hash) is extremely rare, the bug is very unlikely to happen fortunately. This fixes by allowing the updating of the protection bits in the native hash handling to also set (but not clear) the "C" bit, and, in order to also improve performances in the general case, by always setting that bit on newly inserted hash PTE so that writeback really never happens. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org> |
||
|---|---|---|
| .. | ||
| 4xx_mmu.c | ||
| 44x_mmu.c | ||
| fault.c | ||
| fsl_booke_mmu.c | ||
| hash_low_32.S | ||
| hash_low_64.S | ||
| hash_native_64.c | ||
| hash_utils_64.c | ||
| hugetlbpage.c | ||
| imalloc.c | ||
| init_32.c | ||
| init_64.c | ||
| lmb.c | ||
| Makefile | ||
| mem.c | ||
| mmap.c | ||
| mmu_context_32.c | ||
| mmu_context_64.c | ||
| mmu_decl.h | ||
| numa.c | ||
| pgtable_32.c | ||
| pgtable_64.c | ||
| ppc_mmu_32.c | ||
| slb_low.S | ||
| slb.c | ||
| stab.c | ||
| tlb_32.c | ||
| tlb_64.c | ||