From: Shiraz Hashim <shashim@xxxxxxxxxxxxxx>
Subject: mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range
walk_page_range() silently skips vma having VM_PFNMAP set, which leads to
undesirable behaviour at client end (who called walk_page_range).
Userspace applications get the wrong data, so the effect is like just
confusing users (if the applications just display the data) or sometimes
killing the processes (if the applications do something with
misunderstanding virtual addresses due to the wrong data.)
For example for pagemap_read, when no callbacks are called against
VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual
address range at wrong index.
Eventually userspace may get wrong pagemap data for a task. Corresponding
to a VM_PFNMAP marked vma region, kernel may report mappings from
subsequent vma regions. User space in turn may account more pages (than
really are) to the task.
In my case I was using procmem, procrack (Android utility) which uses
pagemap interface to account RSS pages of a task. Due to this bug it was
giving a wrong picture for vmas (with VM_PFNMAP set).
Fixes: a9ff785e4437 ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas")
Signed-off-by: Shiraz Hashim <shashim@xxxxxxxxxxxxxx>
Acked-by: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx> [3.10+]
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/pagewalk.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff -puN mm/pagewalk.c~mm-pagewalk-call-pte_hole-for-vm_pfnmap-during-walk_page_range mm/pagewalk.c
--- a/mm/pagewalk.c~mm-pagewalk-call-pte_hole-for-vm_pfnmap-during-walk_page_range
+++ a/mm/pagewalk.c
@@ -199,7 +199,10 @@ int walk_page_range(unsigned long addr,
*/
if ((vma->vm_start <= addr) &&
(vma->vm_flags & VM_PFNMAP)) {
- next = vma->vm_end;
+ if (walk->pte_hole)
+ err = walk->pte_hole(addr, next, walk);
+ if (err)
+ break;
pgd = pgd_offset(walk->mm, next);
continue;
}
_
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html