On 04/17/2015 12:10 AM, Hillf Danton wrote:
Now that we have hole punching support for hugetlbfs, we can
also support the MADV_REMOVE interface to it.
Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
---
mm/madvise.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index d551475..c4a1027 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -299,7 +299,7 @@ static long madvise_remove(struct vm_area_struct
*vma,
*prev = NULL; /* tell sys_madvise we drop mmap_sem */
- if (vma->vm_flags & (VM_LOCKED | VM_HUGETLB))
+ if (vma->vm_flags & VM_LOCKED)
return -EINVAL;
f = vma->vm_file;
--
2.1.0
After the above change offset is computed,
offset = (loff_t)(start - vma->vm_start)
+ ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
and I wonder if it is correct for huge page mapping.
I think it will be correct.
The above will be a (base) page size aligned offset into the file.
This offset will be huge page aligned in the fallocate hole punch
code.
/*
* For hole punch round up the beginning offset of the hole and
* round down the end.
*/
hole_start = (offset + hpage_size - 1) & ~huge_page_mask(h);
hole_end = (offset + len - (hpage_size - 1)) * ~huge_page_mask(h);
Was the alignment your concern, or something else?