In gather_pte_stats() a THP pmd is cast into a pte, which is wrong because the layouts may differ depending on the architecture. On s390 this will lead to inaccurate numap_maps accounting in /proc because of misguided pte_present() and pte_dirty() checks on the fake pte. On other architectures pte_present() and pte_dirty() may work by chance, but there will be an issue with direct-access (dax) mappings w/o underlying struct pages when HAVE_PTE_SPECIAL is set and THP is available. In vm_normal_page() the fake pte will be checked with pte_special() and because there is no "special" bit in a pmd, this will always return false and the VM_PFNMAP | VM_MIXEDMAP checking will be skipped. On dax mappings w/o struct pages, an invalid struct page pointer will then be returned that can crash the kernel. This crash may be a theoretical issue so far, the RAM block device driver seems to be safe as there should be struct pages present. Not sure about the axonram or nvdimm (putting Maintainers on cc), but the dcssblk on s390 is safe until there will be large page support in z/VM. This patch fixes the numa_maps THP handling by introducing new "_pmd" variants of the can_gather_numa_stats() and vm_normal_page() functions. Any thoughts? Gerald Schaefer (1): numa: fix /proc/<pid>/numa_maps for THP fs/proc/task_mmu.c | 29 ++++++++++++++++++++++++++--- include/linux/mm.h | 2 ++ mm/memory.c | 38 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 66 insertions(+), 3 deletions(-) -- 2.3.9 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>