From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx169.postini.com [74.125.245.169]) by kanga.kvack.org (Postfix) with SMTP id 412B06B0002 for ; Tue, 2 Apr 2013 07:32:34 -0400 (EDT) Received: by mail-vc0-f181.google.com with SMTP id hv10so289206vcb.12 for ; Tue, 02 Apr 2013 04:32:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1364836882-9713-2-git-send-email-n-horiguchi@ah.jp.nec.com> References: <1364836882-9713-1-git-send-email-n-horiguchi@ah.jp.nec.com> <1364836882-9713-2-git-send-email-n-horiguchi@ah.jp.nec.com> Date: Tue, 2 Apr 2013 20:32:33 +0900 Message-ID: Subject: Re: [PATCH v2 1/2] hugetlbfs: stop setting VM_DONTDUMP in initializing vma(VM_HUGETLB) From: HATAYAMA Daisuke Content-Type: multipart/alternative; boundary=047d7b6dc9a8eaba7404d95f172e Sender: owner-linux-mm@kvack.org List-ID: To: Naoya Horiguchi Cc: Andrew Morton , Mel Gorman , Hugh Dickins , Rik van Riel , KOSAKI Motohiro , Konstantin Khlebnikov , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org --047d7b6dc9a8eaba7404d95f172e Content-Type: text/plain; charset=ISO-8859-1 2013/4/2 Naoya Horiguchi > 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 > > @@ -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 --047d7b6dc9a8eaba7404d95f172e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2013/4/2 Naoya Horiguchi <n-hor= iguchi@ah.jp.nec.com>
Currently we fail to include any data on hugepages into coredump,
because VM_DONTDUMP is set on hugetlbfs's vma. This behavior was recent= ly
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:
=A0- add 'return 0' in hugepage memory check
&= lt;cut>
@@ -1137,6 +1137,7 @@ static unsigned long vma_dump_size(struct vm_area_str= uct *vma,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto whole;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!(vma->vm_flags & VM_SHARED) &am= p;& FILTER(HUGETLB_PRIVATE))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto whole;
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
=A0 =A0 =A0 =A0 }

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 beh= aviour that doesn't follow
the description in Documentation/filesystems/proc.txt that:

=A0 Note= bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only
= =A0 effected by bit 5-6.

Right?

Thanks.
HATAYAMA, Daisuke<= br>
--047d7b6dc9a8eaba7404d95f172e-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org