lkml.org 
[lkml]   [2016]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH RFC 0/1] numa: fix /proc/<pid>/numa_maps for THP
Date
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

\
 
 \ /
  Last update: 2016-02-05 16:41    [W:0.051 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site