| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20080902111639.1AB7.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date: Tue, 02 Sep 2008 11:18:33 +0900
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>
Cc: kosaki.motohiro@...fujitsu.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>,
sugita <yumiko.sugita.yf@...achi.com>,
Satoshi OSHIMA <satoshi.oshima.fk@...achi.com>
Subject: Re: [PATCH] coredump_filter: add hugepage core dumping
> > 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
>
> Hugetlb VMAs fall also into one of the lowest 4 bit case.
> If you introduce the hugetlb bit (bit 5), you'd better describe that
> the hugetlb bit takes precedence over the lowest 4 bits.
Thank you good review.
I updated that documentations.
=====================================================================
Subject: [PATCH v2] coredump_filter: add hugepage core dumping
Now, hugepage's vma has VM_RESERVED flag in order not to being swapped.
But VM_RESERVED vma isn't core dumped because this flag is often used for
some kernel vmas (e.g. vmalloc, sound related).
Then hugepage is never dumped and it can't be debugged easily.
Many developers want hugepages to be included into core-dump.
I think current VM_RESERVED default dumping bahavior is good,
then I'd like to add coredump_filter mask.
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>
Tested-by: Adam Litke <agl@...ibm.com>
Acked-by: Adam Litke <agl@...ibm.com>
---
Documentation/filesystems/proc.txt | 6 +++++-
fs/binfmt_elf.c | 6 +++++-
include/linux/sched.h | 3 ++-
3 files changed, 12 insertions(+), 3 deletions(-)
Index: b/Documentation/filesystems/proc.txt
===================================================================
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -2389,15 +2389,19 @@ 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.
+ Note hugetlb memory flag (bit 5) is prior to other bit. then 0x20 mean
+ that hugetlb memory can be dumped, but any other memory can't be dumped.
+
Default value of coredump_filter is 0x3; this means all anonymous memory
segments are dumped.
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,15 @@ 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) {
--
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