Changelog
-----------------
v2 -> v3
- separated /proc/[pid]/core_dump_filter bits into
shared and private mapping pages.
- updated document
v1 -> v2
- updated document
============================================
Subject: [PATCH v3] 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.
However, We can't read VM_RESERVED area in almost case because this area is
often used for I/O mapping area.
then these area reading may change device state and it is definitly undesiable
side-effect.
So, To add hugepage specific bit of the coredump filter is better.
it will be able to hugepage core dumping and doesn't cause any side-effect
to any I/O devices.
In additional, libhugetlb use hugetlb private mapping pages as anonymous page.
Then, hugepage private mapping pages should be core dumped by default.
Then, /proc/[pid]/core_dump_filter has two new bits.
- bit 5 mean hugetlb private mapping pages are dumped or not. (default: yes)
- bit 6 mean hugetlb shared mapping pages are dumped or not. (default: no)
I tested by following method.
% ulimit -c unlimited
% ./crash_hugepage 50
% ./crash_hugepage 50 -p
% ls -lh
% gdb ./crash_hugepage core
%
% echo 0x43 > /proc/self/coredump_filter
% ./crash_hugepage 50
% ./crash_hugepage 50 -p
% ls -lh
% gdb ./crash_hugepage core
crash_hugepage.c
------------------------------------------------
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <string.h>
#include "hugetlbfs.h"
int main(int argc, char** argv){
char* p;
int ch;
int mmap_flags = MAP_SHARED;
int fd;
int nr_pages;
while((ch = getopt(argc, argv, "p")) != -1) ...Changelog:
v1 -> v3
o Coding style fix (Thanks mel, adam)
==========================================
Subject: [PATCH v3] hugepage: support ZERO_PAGE()
Now, hugepage doesn't use zero page at all because almost zero page is only used
for coredumping and hugepage can't core dump ago.
However now, we implemented hugepage coredumping. therefore we should implement
the zero page of hugepage.
This patch do it.
Implementation note:
-------------------------------------------------------------
o Why do we only check VM_SHARED for zero page?
normal page checked as ..
static inline int use_zero_page(struct vm_area_struct *vma)
{
if (vma->vm_flags & (VM_LOCKED | VM_SHARED))
return 0;
return !vma->vm_ops || !vma->vm_ops->fault;
}
First, hugepages never mlock()ed. we don't need concern to VM_LOCKED.
Second, hugetlbfs is pseudo filesystem, not real filesystem and it doesn't
have any file backing.
Then, ops->fault checking is meaningless.
o Why don't we use zero page if !pte.
!pte indicate {pud, pmd} doesn't exist or any error happend.
So, We shouldn't return zero page if any error happend.
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Adam Litke <agl@us.ibm.com>
CC: Hugh Dickins <hugh@veritas.com>
CC: Kawai Hidehiro <hidehiro.kawai.ez@hitachi.com>
CC: Mel Gorman <mel@skynet.ie>
---
mm/hugetlb.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
Index: b/mm/hugetlb.c
===================================================================
--- a/mm/hugetlb.c 2008-09-25 21:22:41.000000000 +0900
+++ b/mm/hugetlb.c 2008-09-26 02:54:10.000000000 +0900
@@ -2071,6 +2071,14 @@ follow_huge_pud(struct mm_struct *mm, un
return NULL;
}
+static int huge_zeropage_ok(pte_t *ptep, int write, int shared)
+{
+ if (!ptep || write || shared)
+ return 0;
+ else
+ return huge_pte_none(huge_ptep_get(ptep));
+}
+
int follow_hugetlb_page(struct mm_struct *mm, ...Hi Kosaki-san, This should be: write 0x21 to the process's proc file. Except for this, it seems OK. Thanks. -- Hidehiro Kawai Hitachi, Systems Development Laboratory Linux Technology Center --
Hi Kawai-san,
new version is attached.
============================================
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: [PATCH v4] coredump_filter: add hugepage core dumping
Changelog
-----------------
v3 -> v4
- fixed documentation typo.
v2 -> v3
- separated /proc/[pid]/core_dump_filter bits into
shared and private mapping pages.
- updated document
v1 -> v2
- updated document
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.
However, We can't read generic VM_RESERVED area because this area is often
IO mapping area.
then these area reading may change device state. it is definitly undesiable
side-effect.
So, To add hugepage specific bit of the coredump filter is better.
it will be able to hugepage core dumping and doesn't cause any side-effect
to any i/o devices.
In additional, libhugetlb use hugetlb private mapping pages as anonymous page.
Then, hugepage private mapping pages should be core dumped by default.
Then, /proc/[pid]/core_dump_filter has two new bits.
- bit 5 mean hugetlb private mapping pages are dumped or not. (default: yes)
- bit 6 mean hugetlb shared mapping pages are dumped or not. (default: no)
I tested by following method.
% ulimit -c unlimited
% ./crash_hugepage 50
% ./crash_hugepage 50 -p
% ls -lh
% gdb ./crash_hugepage core
%
% echo 0x43 > /proc/self/coredump_filter
% ./crash_hugepage 50
% ./crash_hugepage 50 -p
% ls -lh
% gdb ./crash_hugepage core
crash_hugepage.c
------------------------------------------------
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <string.h>
#include "hugetlbfs.h"
int main(int argc, char** ...