From dde27822586dd7a89c91c66d11878f8e19e6b823 Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Wed, 2 Jun 2004 18:01:46 -0700 Subject: [PATCH] [PATCH] hugetlbpage msync() fix From: David Gibson Currently, calling msync() on a hugepage area will cause the kernel to blow up with a bad_page() (at least on ppc64, but I think the problem will exist on other archs too). The msync path attempts to walk pagetables which may not be there, or may have an unusual layout for hugepages. Lucikly we shouldn't need to do anything for an msync on hugetlbfs beyond flushing the cache, so this patch should be sufficient to fix the problem. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- mm/msync.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/mm/msync.c b/mm/msync.c index 5467df544970a..cd5e947dabf29 100644 --- a/mm/msync.c +++ b/mm/msync.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include @@ -106,6 +107,13 @@ static int filemap_sync(struct vm_area_struct * vma, unsigned long address, dir = pgd_offset(vma->vm_mm, address); flush_cache_range(vma, address, end); + + /* For hugepages we can't go walking the page table normally, + * but that's ok, hugetlbfs is memory based, so we don't need + * to do anything more on an msync() */ + if (is_vm_hugetlb_page(vma)) + goto out; + if (address >= end) BUG(); do { @@ -118,7 +126,7 @@ static int filemap_sync(struct vm_area_struct * vma, unsigned long address, * dirty bits. */ flush_tlb_range(vma, end - size, end); - + out: spin_unlock(&vma->vm_mm->page_table_lock); return error; -- 2.53.0