[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080902134850.GA26372@csn.ul.ie>
Date: Tue, 2 Sep 2008 14:48:51 +0100
From: Mel Gorman <mel@....ul.ie>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc: Kawai Hidehiro <hidehiro.kawai.ez@...achi.com>,
Hugh Dickins <hugh@...itas.com>,
William Irwin <wli@...omorphy.com>,
Adam Litke <agl@...ibm.com>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] coredump_filter: add hugepage core dumping
On (28/08/08 14:24), KOSAKI Motohiro didst pronounce:
> 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).
>
The meaning of VM_RESERVED is a bit more complicated than that, but
you're right in that it prevents hugetlbfs files being core-dumped.
> 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.
>
Fair point.
> I think VM_RESERVED default dumping bahavior is good,
> then I'd like to add coredump_filter mask.
>
That aside, it is not always safe to read a VM_RESERVED area without
side-effects.
> This patch doesn't change dafault behavior.
>
I wonder about this and if that is the right thing to do. By default,
core dumps include anonymous private and shared memory. Strictly speaking,
hugetlbfs is a file-backed mapping but it is always a ram-based file and a
private mapping is likely to contain information that would normally be in
a private anonymous mapping. It feels like that information should be core
dumped by default. Would it be better to
1. Distinguish between private and shared hugetlbfs mappings
2. Default dump MAP_PRIVATE hugetlbfs mappings
?
>
> I tested by following method.
>
> # ulimit -c unlimited
> # echo 0x23 > /proc/self/coredump_filter
> # ./hugepage_dump
> # gdb ./hugepage_dump core
>
>
> hugepage_dump.c
> ------------------------------------------------
> #include <sys/ipc.h>
> #include <sys/shm.h>
> #include <sys/types.h>
> #include <unistd.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <errno.h>
> #include <string.h>
>
> #define HUGEPAGE_SIZE (256*1024*1024)
>
> int main(int argc, char** argv)
> {
> int err;
> int shmid;
> int *pval;
> int shm_flags = 0666;
>
> if ((argc >= 2) && (strcmp(argv[1], "-h")==0))
> shm_flags |= SHM_HUGETLB;
>
> err = shmid = shmget(IPC_PRIVATE, HUGEPAGE_SIZE, shm_flags);
> if (err < 0) {
> perror("shmget");
> exit(1);
> }
>
> pval = shmat(shmid, 0, 0);
> if (pval == (void*)-1) {
> perror("shmat");
> exit(1);
> }
>
> *pval = 1;
>
> *(int*)0 = 1;
>
> exit(0);
> }
> -----------------------------------------------------
>
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> CC: Kawai, Hidehiro <hidehiro.kawai.ez@...achi.com>
> CC: Hugh Dickins <hugh@...itas.com>
> CC: William Irwin <wli@...omorphy.com>
> CC: Adam Litke <agl@...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
>
It's not your fault, but the meaning of bit 4 appears to be
undocumented. Offhand, does anyone know if this is intentional?
> 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)
Why is this not just changing to 6?
> #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) {
>
Otherwise, it appears ok.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists