mirror of
https://github.com/torvalds/linux.git
synced 2024-11-02 02:01:29 +00:00
65ba6cdc83
When we demote a slice from 64k to 4k, and we are about to insert an HPTE for a 4k subpage and we notice that there is an existing 64k HPTE, we first invalidate that HPTE before inserting the new 4k subpage HPTE. Since the bits that encode which hash bucket the old HPTE was in overlap with the bits that encode which of the 16 subpages have HPTEs, we need to clear out the subpage HPTE-present bits before starting to insert HPTEs for the 4k subpages. If we don't do that, we can erroneously think that a subpage already has an HPTE when it doesn't. That in itself wouldn't be such a problem except that when we go to update the HPTE that we think is present on machines with a hypervisor, the hypervisor can tell us that the HPTE we think is there is actually there even though it isn't, which can lead to a process getting stuck in a loop, continually faulting. The reason for the confusion is that the AVPN (abbreviated virtual page number) we are looking for in the HPTE for a 4k subpage can actually match the AVPN in a stale HPTE for another 64k page. For example, the HPTE for the 4k subpage at 0x84000f000 will be in the same hash bucket and have the same AVPN as the HPTE for the 64k page at 0x8400f0000. This fixes the code to clear out the subpage HPTE-present bits. Signed-off-by: Paul Mackerras <paulus@samba.org> |
||
|---|---|---|
| .. | ||
| 40x_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 | ||
| init_32.c | ||
| init_64.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 | ||
| slice.c | ||
| stab.c | ||
| subpage-prot.c | ||
| tlb_32.c | ||
| tlb_64.c | ||