2013/4/2 Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx>
You should split this part into another patch. This fix is orthogonal to the bug this patch tries to fix.
The bug you're trying to fix implicitly here is the filtering behaviour that doesn't follow
the description in Documentation/filesystems/proc.txt that:
Note bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only
effected by bit 5-6.
Right?
Thanks.
HATAYAMA, Daisuke
Currently we fail to include any data on hugepages into coredump,
because VM_DONTDUMP is set on hugetlbfs's vma. This behavior was recently
introduced by commit 314e51b98 "mm: kill vma flag VM_RESERVED and
mm->reserved_vm counter". This looks to me a serious regression,
so let's fix it.
ChangeLog v2:
- add 'return 0' in hugepage memory check
<cut>
@@ -1137,6 +1137,7 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma,
goto whole;
if (!(vma->vm_flags & VM_SHARED) && FILTER(HUGETLB_PRIVATE))
goto whole;
+ return 0;
}
You should split this part into another patch. This fix is orthogonal to the bug this patch tries to fix.
The bug you're trying to fix implicitly here is the filtering behaviour that doesn't follow
the description in Documentation/filesystems/proc.txt that:
Note bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only
effected by bit 5-6.
Right?
Thanks.
HATAYAMA, Daisuke