diff options
| author | Andrew Morton <akpm@digeo.com> | 2003-02-05 16:58:57 -0800 |
|---|---|---|
| committer | Linus Torvalds <torvalds@home.transmeta.com> | 2003-02-05 16:58:57 -0800 |
| commit | df79ea4004dd472d22b1ae21bb51f6b4ec3a312e (patch) | |
| tree | 09db9b0a7bc21eb4a842225a2e4526590b9d843d /include | |
| parent | 8a1335e97ac2598f8f5ea8f18c7d8eeb4906e841 (diff) | |
[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.
Diffstat (limited to 'include')
| -rw-r--r-- | include/linux/hugetlb.h | 4 |
1 files changed, 4 insertions, 0 deletions
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 |