[PATCH] page table page->index
I found a situation where page->index for a pagetable page can be set to 0 instead of the correct value. This means that ptep_to_address will return the wrong answer. The problem occurs when remap_pmd_range calls pte_alloc_map and pte_alloc_map needs to allocate a new pte page, because remap_pmd_range has masked off the top bits of the address (to avoid overflow in the computation of `end'), and it passes the masked address to pte_alloc_map. Now we presumably don't need to get from the physical pages mapped by remap_page_range back to the ptes mapping them. But we could easily map some normal pages using ptes in that pagetable page subsequently, and when we call ptep_to_address on their ptes it will give the wrong answer. The patch below fixes the problem. There is a more general question this brings up - some of the procedures which iterate over ranges of ptes will do the wrong thing if the end of the address range is too close to ~0UL, while others are OK. Is this a problem in practice? On i386, ppc, and the 64-bit architectures it isn't since user addresses can't go anywhere near ~0UL, but what about arm or m68k for instance? And BTW, being able to go from a pte pointer to the mm and virtual address that that pte maps is an extremely useful thing on ppc, since it will enable me to do MMU hash-table management at set_pte (and ptep_*) time and thus avoid the extra traversal of the pagetables that I am currently doing in flush_tlb_*. So if you do decide to back out rmap, please leave in the hooks for setting page->mapping and page->index on pagetable pages.
Showing
Please register or sign in to comment