RE: [hugepage] Fix unmap_and_free_vma backout path

Chen, Kenneth W
2006-11-13T06:03:31Z

David Gibson wrote on Sunday, November 12, 2006 9:57 PM
> On Sun, Nov 12, 2006 at 09:29:48PM -0800, Christoph Lameter wrote:
> > On Mon, 13 Nov 2006, 'David Gibson' wrote:
> >
> > > This may not be all we want. Even with this patch, performing such a
> > > failing map on to of an existing mapping will clobber (unmap) that
> > > pre-existing mapping. This is in contrast to the analogous situation
> > > with normal page mappings - mapping on top with a misaligned offset
> > > will fail early enough not to clobber the pre-existing mapping.
> >
> > Then it is best to check the huge page alignment at the
> > same place as regular alignment.
>
> Probably, yes, although it's yet another "if (hugepage)
> specialcase()". But I still think we want the above patch as well.
> It will make sure we correctly back out from any other possible
> failure cases in hugetlbfs_file_mmap() - ones I haven't thought of, or
> which get added later.

Something like this? I haven't tested it yet. But looks plausible
because we already have if is_file_hugepages() in the generic path.

--- ./mm/mmap.c.orig 2006-11-12 22:43:10.000000000 -0800
+++ ./mm/mmap.c 2006-11-12 22:56:23.000000000 -0800
@@ -1375,11 +1375,14 @@ get_unmapped_area(struct file *file, uns
if (addr & ~PAGE_MASK)
return -EINVAL;
if (file && is_file_hugepages(file)) {
+ ret = 0;
/*
* Check if the given range is hugepage aligned, and
* can be made suitable for hugepages.
*/
- ret = prepare_hugepage_range(addr, len);
+ if (pgoff & (~HPAGE_MASK >> PAGE_SHIFT) ||
+ prepare_hugepage_range(addr, len))
+ ret = -EINVAL;
} else {
/*
* Ensure that a normal request is not falling in a