From df79ea4004dd472d22b1ae21bb51f6b4ec3a312e Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Wed, 5 Feb 2003 16:58:57 -0800 Subject: [PATCH] hugetlb mremap fix If you attempt to perform a relocating 4k-aligned mremap and the new address for the map lands on top of a hugepage VMA, do_mremap() will attempt to perform a 4k-aligned unmap inside the hugetlb VMA. The hugetlb layer goes BUG. Fix that by trapping the poorly-aligned unmap attempt in do_munmap(). do_remap() will then fall through without having done anything to the place where it tests for a hugetlb VMA. It would be neater to perform these checks on entry to do_mremap(), but that would incur another VMA lookup. Also, if you attempt to perform a 4k-aligned and/or sized munmap() inside a hugepage VMA the same BUG happens. This patch fixes that too. This all means that an mremap attempt against a hugetlb area will fail, but only after having unmapped the source pages. That's a bit messy, but supporting hugetlb mremap doesn't seem worth it, and completely disallowing it will add overhead to normal mremaps. --- include/linux/hugetlb.h | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'include/linux') diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index b51d51d05190..370411eaaba2 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -58,6 +58,10 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma) #define follow_huge_pmd(mm, addr, pmd, write) 0 #define pmd_huge(x) 0 +#ifndef HPAGE_MASK +#define HPAGE_MASK 0 /* Keep the compiler happy */ +#endif + #endif /* !CONFIG_HUGETLB_PAGE */ #ifdef CONFIG_HUGETLBFS -- cgit v1.2.3