All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Litke <agl@us.ibm.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Kawai Hidehiro <hidehiro.kawai.ez@hitachi.com>,
	Hugh Dickins <hugh@veritas.com>,
	William Irwin <wli@holomorphy.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] coredump_filter: add hugepage core dumping
Date: Thu, 28 Aug 2008 09:48:15 -0500	[thread overview]
Message-ID: <1219934895.14358.40.camel@localhost.localdomain> (raw)
In-Reply-To: <20080828142352.6ABC.KOSAKI.MOTOHIRO@jp.fujitsu.com>

On Thu, 2008-08-28 at 14:24 +0900, KOSAKI Motohiro wrote:
> Now, hugepage's vma has VM_RESERVED flag because it cannot be swapped.
> 
> and VM_RESERVED vma isn't core dumped because its flag often be used for
> kernel internal vma (e.g. vmalloc, sound related).
> 
> So, hugepage is never dumped and it indicate hugepages's program can't be debugged easily.
> 
> In these days, demand on making use of hugepage is increasing.
> IMO, native support for coredump of hugepage is useful.
> 
> 
> I think VM_RESERVED default dumping bahavior is good,
> then I'd like to add coredump_filter mask.
> 
> This patch doesn't change dafault behavior.

I have tested this using both the provided C program and with a program
that used libhugetlbfs to back its text and data segments with huge
pages.  This seems to work as expected.  From a hugetlbfs perspective,
this seems like a reasonable patch to me.

> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Kawai, Hidehiro <hidehiro.kawai.ez@hitachi.com>
> CC: Hugh Dickins <hugh@veritas.com>
> CC: William Irwin <wli@holomorphy.com>
> CC: Adam Litke <agl@us.ibm.com>

Tested-by: Adam Litke <agl@us.ibm.com>
Acked-by: Adam Litke <agl@us.ibm.com>

> ---
>  Documentation/filesystems/proc.txt |    3 ++-
>  fs/binfmt_elf.c                    |    7 ++++++-
>  include/linux/sched.h              |    3 ++-
>  3 files changed, 10 insertions(+), 3 deletions(-)
> 
> Index: b/Documentation/filesystems/proc.txt
> ===================================================================
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -2389,11 +2389,12 @@ will be dumped when the <pid> process is
>  of memory types. If a bit of the bitmask is set, memory segments of the
>  corresponding memory type are dumped, otherwise they are not dumped.
> 
> -The following 4 memory types are supported:
> +The following 5 memory types are supported:
>    - (bit 0) anonymous private memory
>    - (bit 1) anonymous shared memory
>    - (bit 2) file-backed private memory
>    - (bit 3) file-backed shared memory
> +  - (bit 5) hugetlb memory
> 
>    Note that MMIO pages such as frame buffer are never dumped and vDSO pages
>    are always dumped regardless of the bitmask status.
> Index: b/include/linux/sched.h
> ===================================================================
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -402,8 +402,9 @@ extern int get_dumpable(struct mm_struct
>  #define MMF_DUMP_MAPPED_PRIVATE	4
>  #define MMF_DUMP_MAPPED_SHARED	5
>  #define MMF_DUMP_ELF_HEADERS	6
> +#define MMF_DUMP_HUGETLB	7
>  #define MMF_DUMP_FILTER_SHIFT	MMF_DUMPABLE_BITS
> -#define MMF_DUMP_FILTER_BITS	5
> +#define MMF_DUMP_FILTER_BITS	(MMF_DUMP_HUGETLB - MMF_DUMP_ANON_PRIVATE + 1)
>  #define MMF_DUMP_FILTER_MASK \
>  	(((1 << MMF_DUMP_FILTER_BITS) - 1) << MMF_DUMP_FILTER_SHIFT)
>  #define MMF_DUMP_FILTER_DEFAULT \
> Index: b/fs/binfmt_elf.c
> ===================================================================
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1160,11 +1160,16 @@ static unsigned long vma_dump_size(struc
>  	if (vma->vm_flags & VM_ALWAYSDUMP)
>  		goto whole;
> 
> +#define FILTER(type)	(mm_flags & (1UL << MMF_DUMP_##type))
> +
> +	if ((vma->vm_flags & VM_HUGETLB) && FILTER(HUGETLB))
> +		goto whole;
> +
>  	/* Do not dump I/O mapped devices or special mappings */
>  	if (vma->vm_flags & (VM_IO | VM_RESERVED))
>  		return 0;
> 
> -#define FILTER(type)	(mm_flags & (1UL << MMF_DUMP_##type))
> 
>  	/* By default, dump shared memory if mapped from an anonymous file. */
>  	if (vma->vm_flags & VM_SHARED) {
> 
> 
-- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center


  reply	other threads:[~2008-08-28 14:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-28  5:24 [PATCH] coredump_filter: add hugepage core dumping KOSAKI Motohiro
2008-08-28 14:48 ` Adam Litke [this message]
2008-08-28 14:59   ` KOSAKI Motohiro
2008-08-28 16:38 ` Hugh Dickins
2008-08-28 23:35   ` KOSAKI Motohiro
2008-08-29 15:28     ` Adam Litke
2008-09-02  1:21       ` [PATCH] hugepage: support ZERO_PAGE() KOSAKI Motohiro
2008-09-02 14:22         ` Mel Gorman
2008-09-02 15:13           ` Mel Gorman
2008-09-02 16:27         ` Mel Gorman
2008-09-02 17:27         ` Adam Litke
2008-09-01  6:00 ` [PATCH] coredump_filter: add hugepage core dumping Hidehiro Kawai
2008-09-02  2:18   ` KOSAKI Motohiro
2008-09-02 13:48 ` Mel Gorman
2008-09-05  8:06   ` KOSAKI Motohiro
2008-09-08  1:51   ` Hidehiro Kawai
2008-09-09 11:20     ` KOSAKI Motohiro
2008-09-10  6:04     ` Roland McGrath
2008-09-10  6:53       ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1219934895.14358.40.camel@localhost.localdomain \
    --to=agl@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=hugh@veritas.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wli@holomorphy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.