From: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Hugh Dickins <hugh@veritas.com>, Adam Litke <agl@us.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Mel Gorman <mel@csn.ul.ie>, sugita <yumiko.sugita.yf@hitachi.com>,
Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>
Subject: Re: [PATCH 1/2] coredump_filter: add hugepage dumping v3
Date: Tue, 30 Sep 2008 21:17:04 +0900 [thread overview]
Message-ID: <48E218C0.2030905@hitachi.com> (raw)
In-Reply-To: <20080925204323.69E5.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Hi Kosaki-san,
KOSAKI Motohiro wrote:
> Index: b/Documentation/filesystems/proc.txt
> ===================================================================
> --- a/Documentation/filesystems/proc.txt 2008-09-25 21:19:13.000000000 +0900
> +++ b/Documentation/filesystems/proc.txt 2008-09-25 21:21:05.000000000 +0900
> @@ -2408,24 +2408,29 @@ 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 7 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 4) ELF header pages in file-backed private memory areas (it is
> effective only if the bit 2 is cleared)
> + - (bit 5) hugetlb private memory
> + - (bit 6) hugetlb shared memory
>
> Note that MMIO pages such as frame buffer are never dumped and vDSO pages
> are always dumped regardless of the bitmask status.
>
> -Default value of coredump_filter is 0x3; this means all anonymous memory
> -segments are dumped.
> + Note bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only
> + effected by bit 5-6.
> +
> +Default value of coredump_filter is 0x23; this means all anonymous memory
> +segments and hugetlb private memory are dumped.
>
> If you don't want to dump all shared memory segments attached to pid 1234,
> -write 1 to the process's proc file.
> +write 21 to the process's proc file.
This should be:
write 0x21 to the process's proc file.
Except for this, it seems OK. Thanks.
Reviewed-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
> - $ echo 0x1 > /proc/1234/coredump_filter
> + $ echo 0x21 > /proc/1234/coredump_filter
>
> When a new process is created, the process inherits the bitmask status from its
> parent. It is useful to set up coredump_filter before the program runs.
--
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center
next prev parent reply other threads:[~2008-09-30 12:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-25 11:52 [PATCH 1/2] coredump_filter: add hugepage dumping v3 KOSAKI Motohiro
2008-09-25 11:54 ` [PATCH 2/2] hugepage: support ZERO_PAGE() KOSAKI Motohiro
2008-09-30 12:17 ` Hidehiro Kawai [this message]
2008-10-01 2:57 ` [PATCH] coredump_filter: add hugepage dumping v4 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=48E218C0.2030905@hitachi.com \
--to=hidehiro.kawai.ez@hitachi.com \
--cc=agl@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=satoshi.oshima.fk@hitachi.com \
--cc=torvalds@linux-foundation.org \
--cc=yumiko.sugita.yf@hitachi.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.