Naoya Horiguchi wrote:
> On Thu, Mar 28, 2013 at 09:03:16PM +0400, Konstantin Khlebnikov wrote:
>> Naoya Horiguchi wrote:
>>> 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.
>>
>> That was introduced in my patch? Really?
>> Here was VM_RESERVED and it had the same effect as VM_DONTDUMP. At least I
>> thought so.
>
> vma_dump_size() does like this (the diff is the one in 314e51b98):
>
> static unsigned long vma_dump_size(struct vm_area_struct *vma,
> unsigned long mm_flags)
> {
> #define FILTER(type) (mm_flags& (1UL<< MMF_DUMP_##type))
>
> /* always dump the vdso and vsyscall sections */
> if (always_dump_vma(vma))
> goto whole;
>
> if (vma->vm_flags& VM_DONTDUMP)
> return 0;
>
> /* Hugetlb memory check */
> if (vma->vm_flags& VM_HUGETLB) {
> if ((vma->vm_flags& VM_SHARED)&& FILTER(HUGETLB_SHARED))
> goto whole;
> if (!(vma->vm_flags& VM_SHARED)&& FILTER(HUGETLB_PRIVATE))
> goto whole;
> }
>
> /* Do not dump I/O mapped devices or special mappings */
> - if (vma->vm_flags& (VM_IO | VM_RESERVED))
> + if (vma->vm_flags& VM_IO)
> return 0;
>
> We have hugetlb memory check after VM_DONTDUMP check, so the following
> changed the behavior.
Ok, I missed this in my patch.
>
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -110,7 +110,7 @@ static int hugetlbfs_file_mmap(struct file *file,
> struct vm_area_struct *vma)
> * way when do_mmap_pgoff unwinds (may be important on powerpc
> * and ia64).
> */
> - vma->vm_flags |= VM_HUGETLB | VM_RESERVED;
> + vma->vm_flags |= VM_HUGETLB | VM_DONTEXPAND | VM_DONTDUMP;
> vma->vm_ops =&hugetlb_vm_ops;
>
> if (vma->vm_pgoff& (~huge_page_mask(h)>> PAGE_SHIFT))
>
> I think we don't have to set VM_DONTDUMP on hugetlbfs's vma.
Acked-by: Konstantin Khlebnikov <[email protected]>
>
> Thanks,
> Naoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
