It's strange enough to be looking out for anonymous pages in VM_UNPAGED
areas, let's not insert the ZERO_PAGE there - though whether it would
matter will depend on what we decide about ZERO_PAGE refcounting.
But whereas do_anonymous_page may (exceptionally) be called on a
VM_UNPAGED area, do_no_page should never be: just BUG_ON.
Signed-off-by: Hugh Dickins <[email protected]>
---
drivers/char/mem.c | 2 +-
mm/memory.c | 14 ++++++++++++--
2 files changed, 13 insertions(+), 3 deletions(-)
--- unpaged08/drivers/char/mem.c 2005-11-12 09:00:39.000000000 +0000
+++ unpaged09/drivers/char/mem.c 2005-11-17 15:11:57.000000000 +0000
@@ -591,7 +591,7 @@ static inline size_t read_zero_pagealign
if (vma->vm_start > addr || (vma->vm_flags & VM_WRITE) == 0)
goto out_up;
- if (vma->vm_flags & (VM_SHARED | VM_HUGETLB))
+ if (vma->vm_flags & (VM_SHARED | VM_HUGETLB | VM_UNPAGED))
break;
count = vma->vm_end - addr;
if (count > size)
--- unpaged08/mm/memory.c 2005-11-17 15:11:43.000000000 +0000
+++ unpaged09/mm/memory.c 2005-11-17 15:11:57.000000000 +0000
@@ -1812,7 +1812,16 @@ static int do_anonymous_page(struct mm_s
spinlock_t *ptl;
pte_t entry;
- if (write_access) {
+ /*
+ * A VM_UNPAGED vma will normally be filled with present ptes
+ * by remap_pfn_range, and never arrive here; but it might have
+ * holes, or if !VM_DONTEXPAND, mremap might have expanded it.
+ * It's weird enough handling anon pages in unpaged vmas, we do
+ * not want to worry about ZERO_PAGEs too (it may or may not
+ * matter if their counts wrap): just give them anon pages.
+ */
+
+ if (write_access || (vma->vm_flags & VM_UNPAGED)) {
/* Allocate our own private page. */
pte_unmap(page_table);
@@ -1887,6 +1896,7 @@ static int do_no_page(struct mm_struct *
int anon = 0;
pte_unmap(page_table);
+ BUG_ON(vma->vm_flags & VM_UNPAGED);
if (vma->vm_file) {
mapping = vma->vm_file->f_mapping;
@@ -1962,7 +1972,7 @@ retry:
inc_mm_counter(mm, anon_rss);
lru_cache_add_active(new_page);
page_add_anon_rmap(new_page, vma, address);
- } else if (!(vma->vm_flags & VM_UNPAGED)) {
+ } else {
inc_mm_counter(mm, file_rss);
page_add_file_rmap(new_page);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
