All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
@ 2012-03-07 17:00 ` Jason Baron
  0 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 17:00 UTC (permalink / raw)
  To: mcgrathr; +Cc: akpm, avi, linux-kernel, qemu-devel

Hi,

The motivation for this change was that I was looking at a way for a qemu-kvm
process, to exclude the guest memory from its core dump, which can be quite
large. There are already a number of filter flags in
/proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
kernel memory, not specific address ranges (which is needed in this case).

Since there are no more vma flags available, the first patch eliminates the
need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
mark vdso and vsyscall pages. However, it is simple enough to check if a vma
covers a vdso or vsyscall page without the need for this flag.

The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new 
'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
work the same as before unless 'MADV_DONTDUMP' is set on the region.

The qemu code which implements this features is at:
http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch

In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.

I also believe that the 'MADV_DONTDUMP' flag might be useful for security
sensitive apps, which might want to select which areas are dumped.

Thanks,

-Jason 


Jason Baron (2):
  core dump: drop VM_ALWAYSDUMP flag
  core dump: add a new VM_DONTDUMP flag

 arch/arm/kernel/process.c          |    2 +-
 arch/hexagon/kernel/vdso.c         |    3 +--
 arch/mips/kernel/vdso.c            |    3 +--
 arch/powerpc/kernel/vdso.c         |    3 +--
 arch/s390/kernel/vdso.c            |    3 +--
 arch/sh/kernel/vsyscall/vsyscall.c |    3 +--
 arch/tile/mm/elf.c                 |    3 +--
 arch/unicore32/kernel/process.c    |    2 +-
 arch/x86/um/mem_32.c               |    8 --------
 arch/x86/um/vdso/vma.c             |    3 +--
 arch/x86/vdso/vdso32-setup.c       |   11 ++---------
 arch/x86/vdso/vma.c                |    3 +--
 fs/binfmt_elf.c                    |   23 +++++++++++++++++++++--
 include/asm-generic/mman-common.h  |    3 +++
 include/linux/mm.h                 |    2 +-
 mm/madvise.c                       |    8 ++++++++
 mm/memory.c                        |    8 +-------
 17 files changed, 46 insertions(+), 45 deletions(-)

-- 
1.7.7.6


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Qemu-devel] [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
@ 2012-03-07 17:00 ` Jason Baron
  0 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 17:00 UTC (permalink / raw)
  To: mcgrathr; +Cc: qemu-devel, akpm, avi, linux-kernel

Hi,

The motivation for this change was that I was looking at a way for a qemu-kvm
process, to exclude the guest memory from its core dump, which can be quite
large. There are already a number of filter flags in
/proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
kernel memory, not specific address ranges (which is needed in this case).

Since there are no more vma flags available, the first patch eliminates the
need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
mark vdso and vsyscall pages. However, it is simple enough to check if a vma
covers a vdso or vsyscall page without the need for this flag.

The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new 
'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
work the same as before unless 'MADV_DONTDUMP' is set on the region.

The qemu code which implements this features is at:
http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch

In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.

I also believe that the 'MADV_DONTDUMP' flag might be useful for security
sensitive apps, which might want to select which areas are dumped.

Thanks,

-Jason 


Jason Baron (2):
  core dump: drop VM_ALWAYSDUMP flag
  core dump: add a new VM_DONTDUMP flag

 arch/arm/kernel/process.c          |    2 +-
 arch/hexagon/kernel/vdso.c         |    3 +--
 arch/mips/kernel/vdso.c            |    3 +--
 arch/powerpc/kernel/vdso.c         |    3 +--
 arch/s390/kernel/vdso.c            |    3 +--
 arch/sh/kernel/vsyscall/vsyscall.c |    3 +--
 arch/tile/mm/elf.c                 |    3 +--
 arch/unicore32/kernel/process.c    |    2 +-
 arch/x86/um/mem_32.c               |    8 --------
 arch/x86/um/vdso/vma.c             |    3 +--
 arch/x86/vdso/vdso32-setup.c       |   11 ++---------
 arch/x86/vdso/vma.c                |    3 +--
 fs/binfmt_elf.c                    |   23 +++++++++++++++++++++--
 include/asm-generic/mman-common.h  |    3 +++
 include/linux/mm.h                 |    2 +-
 mm/madvise.c                       |    8 ++++++++
 mm/memory.c                        |    8 +-------
 17 files changed, 46 insertions(+), 45 deletions(-)

-- 
1.7.7.6

^ permalink raw reply	[flat|nested] 30+ messages in thread

* [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
  2012-03-07 17:00 ` [Qemu-devel] " Jason Baron
@ 2012-03-07 17:00   ` Jason Baron
  -1 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 17:00 UTC (permalink / raw)
  To: mcgrathr; +Cc: akpm, avi, linux-kernel, qemu-devel

The VM_ALWAYSDUMP flag is currently used by the coredump code to indicate that
a vma is part of a vsyscall or vdso section, and then always dump it. However, we
can determine if a vma is in in one of these sections by using 'arch_vma_name()',
and thus re-purpose a valuable vma bit.

Signed-off-by: Jason Baron <jbaron@redhat.com>
---
 arch/arm/kernel/process.c          |    2 +-
 arch/hexagon/kernel/vdso.c         |    3 +--
 arch/mips/kernel/vdso.c            |    3 +--
 arch/powerpc/kernel/vdso.c         |    3 +--
 arch/s390/kernel/vdso.c            |    3 +--
 arch/sh/kernel/vsyscall/vsyscall.c |    3 +--
 arch/tile/mm/elf.c                 |    3 +--
 arch/unicore32/kernel/process.c    |    2 +-
 arch/x86/um/mem_32.c               |    8 --------
 arch/x86/um/vdso/vma.c             |    3 +--
 arch/x86/vdso/vdso32-setup.c       |   11 ++---------
 arch/x86/vdso/vma.c                |    3 +--
 fs/binfmt_elf.c                    |   20 ++++++++++++++++++--
 include/linux/mm.h                 |    1 -
 mm/memory.c                        |    8 +-------
 15 files changed, 31 insertions(+), 45 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 971d65c..565ac89 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -536,7 +536,7 @@ int vectors_user_mapping(void)
 	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
 				       VM_READ | VM_EXEC |
 				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
+				       VM_RESERVED,
 				       NULL);
 }
 
diff --git a/arch/hexagon/kernel/vdso.c b/arch/hexagon/kernel/vdso.c
index 16277c3..f212a45 100644
--- a/arch/hexagon/kernel/vdso.c
+++ b/arch/hexagon/kernel/vdso.c
@@ -78,8 +78,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	/* MAYWRITE to allow gdb to COW and set breakpoints. */
 	ret = install_special_mapping(mm, vdso_base, PAGE_SIZE,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      &vdso_page);
 
 	if (ret)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index e5cdfd6..0f1af58 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -88,8 +88,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, PAGE_SIZE,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      &vdso_page);
 
 	if (ret)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 7d14bb6..af58021 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -272,8 +272,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 */
 	rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 				     VM_READ|VM_EXEC|
-				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				     VM_ALWAYSDUMP,
+				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc) {
 		current->mm->context.vdso_base = 0;
diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index d73630b..25c838c 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -262,8 +262,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 */
 	rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 				     VM_READ|VM_EXEC|
-				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				     VM_ALWAYSDUMP,
+				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc)
 		current->mm->context.vdso_base = 0;
diff --git a/arch/sh/kernel/vsyscall/vsyscall.c b/arch/sh/kernel/vsyscall/vsyscall.c
index 1d6d51a..5ca5797 100644
--- a/arch/sh/kernel/vsyscall/vsyscall.c
+++ b/arch/sh/kernel/vsyscall/vsyscall.c
@@ -73,8 +73,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, PAGE_SIZE,
 				      VM_READ | VM_EXEC |
-				      VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC |
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
 				      syscall_pages);
 	if (unlikely(ret))
 		goto up_fail;
diff --git a/arch/tile/mm/elf.c b/arch/tile/mm/elf.c
index 55e58e9..c4b3ed8 100644
--- a/arch/tile/mm/elf.c
+++ b/arch/tile/mm/elf.c
@@ -126,8 +126,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 	vdso_base = VDSO_BASE;
 	retval = install_special_mapping(mm, vdso_base, PAGE_SIZE,
 					 VM_READ|VM_EXEC|
-					 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-					 VM_ALWAYSDUMP,
+					 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 					 vdso_pages);
 
 #ifndef __tilegx__
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index 52edc2b..432b429 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -381,7 +381,7 @@ int vectors_user_mapping(void)
 	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
 				       VM_READ | VM_EXEC |
 				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
+				       VM_RESERVED,
 				       NULL);
 }
 
diff --git a/arch/x86/um/mem_32.c b/arch/x86/um/mem_32.c
index 639900a..f40281e 100644
--- a/arch/x86/um/mem_32.c
+++ b/arch/x86/um/mem_32.c
@@ -23,14 +23,6 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
 
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
-
 	return 0;
 }
 __initcall(gate_vma_init);
diff --git a/arch/x86/um/vdso/vma.c b/arch/x86/um/vdso/vma.c
index 91f4ec9..af91901 100644
--- a/arch/x86/um/vdso/vma.c
+++ b/arch/x86/um/vdso/vma.c
@@ -64,8 +64,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	err = install_special_mapping(mm, um_vdso_addr, PAGE_SIZE,
 		VM_READ|VM_EXEC|
-		VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-		VM_ALWAYSDUMP,
+		VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 		vdsop);
 
 	up_write(&mm->mmap_sem);
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 468d591..b4d43dd 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -250,13 +250,7 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
+
 	return 0;
 }
 
@@ -352,8 +346,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 		 */
 		ret = install_special_mapping(mm, addr, PAGE_SIZE,
 					      VM_READ|VM_EXEC|
-					      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-					      VM_ALWAYSDUMP,
+					      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 					      vdso32_pages);
 
 		if (ret)
diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index 153407c..17e1827 100644
--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -124,8 +124,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, vdso_size,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      vdso_pages);
 	if (ret) {
 		current->mm->context.vdso = NULL;
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 07d096c..320cc01 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1094,6 +1094,22 @@ out:
  * Jeremy Fitzhardinge <jeremy@sw.oz.au>
  */
 
+/* Determine if the vma should always be output in the coredump */
+static bool always_dump_vma(struct vm_area_struct *vma)
+{
+	const char *vma_name = arch_vma_name(vma);
+
+	if (vma_name) {
+		if ((strcmp(vma_name, "[vdso]") == 0) ||
+		    (strcmp(vma_name, "[vectors]") == 0) ||
+		    (strcmp(vma_name, "[vsyscall]") == 0))
+			return true;
+	}
+	if (vma == get_gate_vma(vma->vm_mm))
+		return true;
+	return false;
+}
+
 /*
  * Decide what to dump of a segment, part, all or none.
  */
@@ -1102,8 +1118,8 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma,
 {
 #define FILTER(type)	(mm_flags & (1UL << MMF_DUMP_##type))
 
-	/* The vma can be set up to tell us the answer directly.  */
-	if (vma->vm_flags & VM_ALWAYSDUMP)
+	/* always dump the vdso and vsyscall sections */
+	if (always_dump_vma(vma))
 		goto whole;
 
 	/* Hugetlb memory check */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 17b27cd..a296709 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -111,7 +111,6 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_HUGEPAGE	0x01000000	/* MADV_HUGEPAGE marked this vma */
 #endif
 #define VM_INSERTPAGE	0x02000000	/* The vma has had "vm_insert_page()" done on it */
-#define VM_ALWAYSDUMP	0x04000000	/* Always include in core dumps */
 
 #define VM_CAN_NONLINEAR 0x08000000	/* Has ->fault & does nonlinear pages */
 #define VM_MIXEDMAP	0x10000000	/* Can contain "struct page" and pure PFN pages */
diff --git a/mm/memory.c b/mm/memory.c
index fa2f04e..9b55ab0 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3611,13 +3611,7 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
+
 	return 0;
 }
 __initcall(gate_vma_init);
-- 
1.7.7.6


^ permalink raw reply related	[flat|nested] 30+ messages in thread

* [Qemu-devel] [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
@ 2012-03-07 17:00   ` Jason Baron
  0 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 17:00 UTC (permalink / raw)
  To: mcgrathr; +Cc: qemu-devel, akpm, avi, linux-kernel

The VM_ALWAYSDUMP flag is currently used by the coredump code to indicate that
a vma is part of a vsyscall or vdso section, and then always dump it. However, we
can determine if a vma is in in one of these sections by using 'arch_vma_name()',
and thus re-purpose a valuable vma bit.

Signed-off-by: Jason Baron <jbaron@redhat.com>
---
 arch/arm/kernel/process.c          |    2 +-
 arch/hexagon/kernel/vdso.c         |    3 +--
 arch/mips/kernel/vdso.c            |    3 +--
 arch/powerpc/kernel/vdso.c         |    3 +--
 arch/s390/kernel/vdso.c            |    3 +--
 arch/sh/kernel/vsyscall/vsyscall.c |    3 +--
 arch/tile/mm/elf.c                 |    3 +--
 arch/unicore32/kernel/process.c    |    2 +-
 arch/x86/um/mem_32.c               |    8 --------
 arch/x86/um/vdso/vma.c             |    3 +--
 arch/x86/vdso/vdso32-setup.c       |   11 ++---------
 arch/x86/vdso/vma.c                |    3 +--
 fs/binfmt_elf.c                    |   20 ++++++++++++++++++--
 include/linux/mm.h                 |    1 -
 mm/memory.c                        |    8 +-------
 15 files changed, 31 insertions(+), 45 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 971d65c..565ac89 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -536,7 +536,7 @@ int vectors_user_mapping(void)
 	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
 				       VM_READ | VM_EXEC |
 				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
+				       VM_RESERVED,
 				       NULL);
 }
 
diff --git a/arch/hexagon/kernel/vdso.c b/arch/hexagon/kernel/vdso.c
index 16277c3..f212a45 100644
--- a/arch/hexagon/kernel/vdso.c
+++ b/arch/hexagon/kernel/vdso.c
@@ -78,8 +78,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	/* MAYWRITE to allow gdb to COW and set breakpoints. */
 	ret = install_special_mapping(mm, vdso_base, PAGE_SIZE,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      &vdso_page);
 
 	if (ret)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index e5cdfd6..0f1af58 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -88,8 +88,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, PAGE_SIZE,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      &vdso_page);
 
 	if (ret)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 7d14bb6..af58021 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -272,8 +272,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 */
 	rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 				     VM_READ|VM_EXEC|
-				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				     VM_ALWAYSDUMP,
+				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc) {
 		current->mm->context.vdso_base = 0;
diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index d73630b..25c838c 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -262,8 +262,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 */
 	rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 				     VM_READ|VM_EXEC|
-				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				     VM_ALWAYSDUMP,
+				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc)
 		current->mm->context.vdso_base = 0;
diff --git a/arch/sh/kernel/vsyscall/vsyscall.c b/arch/sh/kernel/vsyscall/vsyscall.c
index 1d6d51a..5ca5797 100644
--- a/arch/sh/kernel/vsyscall/vsyscall.c
+++ b/arch/sh/kernel/vsyscall/vsyscall.c
@@ -73,8 +73,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, PAGE_SIZE,
 				      VM_READ | VM_EXEC |
-				      VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC |
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
 				      syscall_pages);
 	if (unlikely(ret))
 		goto up_fail;
diff --git a/arch/tile/mm/elf.c b/arch/tile/mm/elf.c
index 55e58e9..c4b3ed8 100644
--- a/arch/tile/mm/elf.c
+++ b/arch/tile/mm/elf.c
@@ -126,8 +126,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 	vdso_base = VDSO_BASE;
 	retval = install_special_mapping(mm, vdso_base, PAGE_SIZE,
 					 VM_READ|VM_EXEC|
-					 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-					 VM_ALWAYSDUMP,
+					 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 					 vdso_pages);
 
 #ifndef __tilegx__
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index 52edc2b..432b429 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -381,7 +381,7 @@ int vectors_user_mapping(void)
 	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
 				       VM_READ | VM_EXEC |
 				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
+				       VM_RESERVED,
 				       NULL);
 }
 
diff --git a/arch/x86/um/mem_32.c b/arch/x86/um/mem_32.c
index 639900a..f40281e 100644
--- a/arch/x86/um/mem_32.c
+++ b/arch/x86/um/mem_32.c
@@ -23,14 +23,6 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
 
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
-
 	return 0;
 }
 __initcall(gate_vma_init);
diff --git a/arch/x86/um/vdso/vma.c b/arch/x86/um/vdso/vma.c
index 91f4ec9..af91901 100644
--- a/arch/x86/um/vdso/vma.c
+++ b/arch/x86/um/vdso/vma.c
@@ -64,8 +64,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	err = install_special_mapping(mm, um_vdso_addr, PAGE_SIZE,
 		VM_READ|VM_EXEC|
-		VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-		VM_ALWAYSDUMP,
+		VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 		vdsop);
 
 	up_write(&mm->mmap_sem);
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 468d591..b4d43dd 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -250,13 +250,7 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
+
 	return 0;
 }
 
@@ -352,8 +346,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 		 */
 		ret = install_special_mapping(mm, addr, PAGE_SIZE,
 					      VM_READ|VM_EXEC|
-					      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-					      VM_ALWAYSDUMP,
+					      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 					      vdso32_pages);
 
 		if (ret)
diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index 153407c..17e1827 100644
--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -124,8 +124,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, vdso_size,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      vdso_pages);
 	if (ret) {
 		current->mm->context.vdso = NULL;
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 07d096c..320cc01 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1094,6 +1094,22 @@ out:
  * Jeremy Fitzhardinge <jeremy@sw.oz.au>
  */
 
+/* Determine if the vma should always be output in the coredump */
+static bool always_dump_vma(struct vm_area_struct *vma)
+{
+	const char *vma_name = arch_vma_name(vma);
+
+	if (vma_name) {
+		if ((strcmp(vma_name, "[vdso]") == 0) ||
+		    (strcmp(vma_name, "[vectors]") == 0) ||
+		    (strcmp(vma_name, "[vsyscall]") == 0))
+			return true;
+	}
+	if (vma == get_gate_vma(vma->vm_mm))
+		return true;
+	return false;
+}
+
 /*
  * Decide what to dump of a segment, part, all or none.
  */
@@ -1102,8 +1118,8 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma,
 {
 #define FILTER(type)	(mm_flags & (1UL << MMF_DUMP_##type))
 
-	/* The vma can be set up to tell us the answer directly.  */
-	if (vma->vm_flags & VM_ALWAYSDUMP)
+	/* always dump the vdso and vsyscall sections */
+	if (always_dump_vma(vma))
 		goto whole;
 
 	/* Hugetlb memory check */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 17b27cd..a296709 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -111,7 +111,6 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_HUGEPAGE	0x01000000	/* MADV_HUGEPAGE marked this vma */
 #endif
 #define VM_INSERTPAGE	0x02000000	/* The vma has had "vm_insert_page()" done on it */
-#define VM_ALWAYSDUMP	0x04000000	/* Always include in core dumps */
 
 #define VM_CAN_NONLINEAR 0x08000000	/* Has ->fault & does nonlinear pages */
 #define VM_MIXEDMAP	0x10000000	/* Can contain "struct page" and pure PFN pages */
diff --git a/mm/memory.c b/mm/memory.c
index fa2f04e..9b55ab0 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3611,13 +3611,7 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
+
 	return 0;
 }
 __initcall(gate_vma_init);
-- 
1.7.7.6

^ permalink raw reply related	[flat|nested] 30+ messages in thread

* [PATCH 2/2] core dump: add a new VM_DONTDUMP flag
  2012-03-07 17:00 ` [Qemu-devel] " Jason Baron
@ 2012-03-07 17:00   ` Jason Baron
  -1 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 17:00 UTC (permalink / raw)
  To: mcgrathr; +Cc: akpm, avi, linux-kernel, qemu-devel

Since we no longer need the VM_ALWAYSDUMP flag, let's use the freed bit for
'VM_DONTDUMP' flag. The idea is to add a new madvise() flag: MADV_DONTDUMP,
which can be set by applications to specifically request memory regions which
should not dump core. The specific application I have in mind is qemu: we
can add a flag there that wouldn't dump all of guest memory when qemu dumps
core. This flag might also be useful for security sensitive apps that want to
absolutely make sure that parts of memory are not dumped.

Signed-off-by: Jason Baron <jbaron@redhat.com>
---
 fs/binfmt_elf.c                   |    3 +++
 include/asm-generic/mman-common.h |    3 +++
 include/linux/mm.h                |    1 +
 mm/madvise.c                      |    8 ++++++++
 4 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 320cc01..df3f950 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1122,6 +1122,9 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma,
 	if (always_dump_vma(vma))
 		goto whole;
 
+	if (vma->vm_flags & VM_DONTDUMP)
+		return 0;
+
 	/* Hugetlb memory check */
 	if (vma->vm_flags & VM_HUGETLB) {
 		if ((vma->vm_flags & VM_SHARED) && FILTER(HUGETLB_SHARED))
diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h
index 787abbb..0016ce3 100644
--- a/include/asm-generic/mman-common.h
+++ b/include/asm-generic/mman-common.h
@@ -48,6 +48,9 @@
 #define MADV_HUGEPAGE	14		/* Worth backing with hugepages */
 #define MADV_NOHUGEPAGE	15		/* Not worth backing with hugepages */
 
+#define MADV_DUMP 16
+#define MADV_DONTDUMP 17
+
 /* compatibility flags */
 #define MAP_FILE	0
 
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a296709..23684cf 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -111,6 +111,7 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_HUGEPAGE	0x01000000	/* MADV_HUGEPAGE marked this vma */
 #endif
 #define VM_INSERTPAGE	0x02000000	/* The vma has had "vm_insert_page()" done on it */
+#define VM_DONTDUMP    0x04000000      /* Do not include in core dump */
 
 #define VM_CAN_NONLINEAR 0x08000000	/* Has ->fault & does nonlinear pages */
 #define VM_MIXEDMAP	0x10000000	/* Can contain "struct page" and pure PFN pages */
diff --git a/mm/madvise.c b/mm/madvise.c
index 74bf193..10b52f8 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -65,6 +65,12 @@ static long madvise_behavior(struct vm_area_struct * vma,
 		}
 		new_flags &= ~VM_DONTCOPY;
 		break;
+	case MADV_DONTDUMP:
+		new_flags |= VM_DONTDUMP;
+		break;
+	case MADV_DUMP:
+		new_flags &= ~VM_DONTDUMP;
+		break;
 	case MADV_MERGEABLE:
 	case MADV_UNMERGEABLE:
 		error = ksm_madvise(vma, start, end, behavior, &new_flags);
@@ -293,6 +299,8 @@ madvise_behavior_valid(int behavior)
 	case MADV_HUGEPAGE:
 	case MADV_NOHUGEPAGE:
 #endif
+	case MADV_DUMP:
+	case MADV_DONTDUMP:
 		return 1;
 
 	default:
-- 
1.7.7.6


^ permalink raw reply related	[flat|nested] 30+ messages in thread

* [Qemu-devel] [PATCH 2/2] core dump: add a new VM_DONTDUMP flag
@ 2012-03-07 17:00   ` Jason Baron
  0 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 17:00 UTC (permalink / raw)
  To: mcgrathr; +Cc: qemu-devel, akpm, avi, linux-kernel

Since we no longer need the VM_ALWAYSDUMP flag, let's use the freed bit for
'VM_DONTDUMP' flag. The idea is to add a new madvise() flag: MADV_DONTDUMP,
which can be set by applications to specifically request memory regions which
should not dump core. The specific application I have in mind is qemu: we
can add a flag there that wouldn't dump all of guest memory when qemu dumps
core. This flag might also be useful for security sensitive apps that want to
absolutely make sure that parts of memory are not dumped.

Signed-off-by: Jason Baron <jbaron@redhat.com>
---
 fs/binfmt_elf.c                   |    3 +++
 include/asm-generic/mman-common.h |    3 +++
 include/linux/mm.h                |    1 +
 mm/madvise.c                      |    8 ++++++++
 4 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 320cc01..df3f950 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1122,6 +1122,9 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma,
 	if (always_dump_vma(vma))
 		goto whole;
 
+	if (vma->vm_flags & VM_DONTDUMP)
+		return 0;
+
 	/* Hugetlb memory check */
 	if (vma->vm_flags & VM_HUGETLB) {
 		if ((vma->vm_flags & VM_SHARED) && FILTER(HUGETLB_SHARED))
diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h
index 787abbb..0016ce3 100644
--- a/include/asm-generic/mman-common.h
+++ b/include/asm-generic/mman-common.h
@@ -48,6 +48,9 @@
 #define MADV_HUGEPAGE	14		/* Worth backing with hugepages */
 #define MADV_NOHUGEPAGE	15		/* Not worth backing with hugepages */
 
+#define MADV_DUMP 16
+#define MADV_DONTDUMP 17
+
 /* compatibility flags */
 #define MAP_FILE	0
 
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a296709..23684cf 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -111,6 +111,7 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_HUGEPAGE	0x01000000	/* MADV_HUGEPAGE marked this vma */
 #endif
 #define VM_INSERTPAGE	0x02000000	/* The vma has had "vm_insert_page()" done on it */
+#define VM_DONTDUMP    0x04000000      /* Do not include in core dump */
 
 #define VM_CAN_NONLINEAR 0x08000000	/* Has ->fault & does nonlinear pages */
 #define VM_MIXEDMAP	0x10000000	/* Can contain "struct page" and pure PFN pages */
diff --git a/mm/madvise.c b/mm/madvise.c
index 74bf193..10b52f8 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -65,6 +65,12 @@ static long madvise_behavior(struct vm_area_struct * vma,
 		}
 		new_flags &= ~VM_DONTCOPY;
 		break;
+	case MADV_DONTDUMP:
+		new_flags |= VM_DONTDUMP;
+		break;
+	case MADV_DUMP:
+		new_flags &= ~VM_DONTDUMP;
+		break;
 	case MADV_MERGEABLE:
 	case MADV_UNMERGEABLE:
 		error = ksm_madvise(vma, start, end, behavior, &new_flags);
@@ -293,6 +299,8 @@ madvise_behavior_valid(int behavior)
 	case MADV_HUGEPAGE:
 	case MADV_NOHUGEPAGE:
 #endif
+	case MADV_DUMP:
+	case MADV_DONTDUMP:
 		return 1;
 
 	default:
-- 
1.7.7.6

^ permalink raw reply related	[flat|nested] 30+ messages in thread

* Re: [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
  2012-03-07 17:00   ` [Qemu-devel] " Jason Baron
@ 2012-03-07 17:59     ` Roland McGrath
  -1 siblings, 0 replies; 30+ messages in thread
From: Roland McGrath @ 2012-03-07 17:59 UTC (permalink / raw)
  To: Jason Baron; +Cc: akpm, avi, linux-kernel, qemu-devel

On Wed, Mar 7, 2012 at 9:00 AM, Jason Baron <jbaron@redhat.com> wrote:
> +       if (vma_name) {
> +               if ((strcmp(vma_name, "[vdso]") == 0) ||
> +                   (strcmp(vma_name, "[vectors]") == 0) ||
> +                   (strcmp(vma_name, "[vsyscall]") == 0))

That's just disgusting.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
@ 2012-03-07 17:59     ` Roland McGrath
  0 siblings, 0 replies; 30+ messages in thread
From: Roland McGrath @ 2012-03-07 17:59 UTC (permalink / raw)
  To: Jason Baron; +Cc: qemu-devel, akpm, avi, linux-kernel

On Wed, Mar 7, 2012 at 9:00 AM, Jason Baron <jbaron@redhat.com> wrote:
> +       if (vma_name) {
> +               if ((strcmp(vma_name, "[vdso]") == 0) ||
> +                   (strcmp(vma_name, "[vectors]") == 0) ||
> +                   (strcmp(vma_name, "[vsyscall]") == 0))

That's just disgusting.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
  2012-03-07 17:59     ` [Qemu-devel] " Roland McGrath
@ 2012-03-07 18:50       ` Jason Baron
  -1 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 18:50 UTC (permalink / raw)
  To: Roland McGrath; +Cc: akpm, avi, linux-kernel, qemu-devel

On Wed, Mar 07, 2012 at 09:59:58AM -0800, Roland McGrath wrote:
> On Wed, Mar 7, 2012 at 9:00 AM, Jason Baron <jbaron@redhat.com> wrote:
> > +       if (vma_name) {
> > +               if ((strcmp(vma_name, "[vdso]") == 0) ||
> > +                   (strcmp(vma_name, "[vectors]") == 0) ||
> > +                   (strcmp(vma_name, "[vsyscall]") == 0))
> 
> That's just disgusting.

well, sure, we can provide an arch interface, for this check. I'm more
concerned with the general idea. If it seems ok, I can re-do this bit
with an arch interface.

Thanks,

-Jason

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
@ 2012-03-07 18:50       ` Jason Baron
  0 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 18:50 UTC (permalink / raw)
  To: Roland McGrath; +Cc: qemu-devel, akpm, avi, linux-kernel

On Wed, Mar 07, 2012 at 09:59:58AM -0800, Roland McGrath wrote:
> On Wed, Mar 7, 2012 at 9:00 AM, Jason Baron <jbaron@redhat.com> wrote:
> > +       if (vma_name) {
> > +               if ((strcmp(vma_name, "[vdso]") == 0) ||
> > +                   (strcmp(vma_name, "[vectors]") == 0) ||
> > +                   (strcmp(vma_name, "[vsyscall]") == 0))
> 
> That's just disgusting.

well, sure, we can provide an arch interface, for this check. I'm more
concerned with the general idea. If it seems ok, I can re-do this bit
with an arch interface.

Thanks,

-Jason

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
  2012-03-07 18:50       ` [Qemu-devel] " Jason Baron
@ 2012-03-07 19:43         ` Roland McGrath
  -1 siblings, 0 replies; 30+ messages in thread
From: Roland McGrath @ 2012-03-07 19:43 UTC (permalink / raw)
  To: Jason Baron; +Cc: akpm, avi, linux-kernel, qemu-devel

> well, sure, we can provide an arch interface, for this check. I'm more
> concerned with the general idea. If it seems ok, I can re-do this bit
> with an arch interface.

Anything based on strcmp is dismal.  VM_ALWAYSDUMP was nice and clean.
A hook along the lines of arch_vma_name would be clean enough I suppose.
In fact, there is only one instance today (tile) where arch_vma_name()!=NULL
wouldn't do just what you need.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
@ 2012-03-07 19:43         ` Roland McGrath
  0 siblings, 0 replies; 30+ messages in thread
From: Roland McGrath @ 2012-03-07 19:43 UTC (permalink / raw)
  To: Jason Baron; +Cc: qemu-devel, akpm, avi, linux-kernel

> well, sure, we can provide an arch interface, for this check. I'm more
> concerned with the general idea. If it seems ok, I can re-do this bit
> with an arch interface.

Anything based on strcmp is dismal.  VM_ALWAYSDUMP was nice and clean.
A hook along the lines of arch_vma_name would be clean enough I suppose.
In fact, there is only one instance today (tile) where arch_vma_name()!=NULL
wouldn't do just what you need.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
  2012-03-07 19:43         ` [Qemu-devel] " Roland McGrath
@ 2012-03-07 21:19           ` Jason Baron
  -1 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 21:19 UTC (permalink / raw)
  To: Roland McGrath; +Cc: akpm, avi, linux-kernel, qemu-devel, cmetcalf

On Wed, Mar 07, 2012 at 11:43:02AM -0800, Roland McGrath wrote:
> > well, sure, we can provide an arch interface, for this check. I'm more
> > concerned with the general idea. If it seems ok, I can re-do this bit
> > with an arch interface.
> 
> Anything based on strcmp is dismal.  VM_ALWAYSDUMP was nice and clean.
> A hook along the lines of arch_vma_name would be clean enough I suppose.
> In fact, there is only one instance today (tile) where arch_vma_name()!=NULL
> wouldn't do just what you need.
> 

Yeah, so I think something like the following would work (adding Tile
maintainer to 'cc list).

Thanks,

-Jason



The VM_ALWAYSDUMP flag is currently used by the coredump code to indicate that
a vma is part of a vsyscall or vdso section, and then always dump it. However, we
can determine if a vma is in one of these sections by using 'arch_vma_name()',
and thus re-purpose a valuable vma bit.

Signed-off-by: Jason Baron <jbaron@redhat.com>
---
 arch/arm/kernel/process.c          |    2 +-
 arch/hexagon/kernel/vdso.c         |    3 +--
 arch/mips/kernel/vdso.c            |    3 +--
 arch/powerpc/kernel/vdso.c         |    3 +--
 arch/s390/kernel/vdso.c            |    3 +--
 arch/sh/kernel/vsyscall/vsyscall.c |    3 +--
 arch/tile/mm/elf.c                 |    3 +--
 arch/unicore32/kernel/process.c    |    2 +-
 arch/x86/um/mem_32.c               |    8 --------
 arch/x86/um/vdso/vma.c             |    3 +--
 arch/x86/vdso/vdso32-setup.c       |   11 ++---------
 arch/x86/vdso/vma.c                |    3 +--
 fs/binfmt_elf.c                    |   22 ++++++++++++++++++++--
 include/linux/mm.h                 |    1 -
 mm/memory.c                        |    8 +-------
 15 files changed, 33 insertions(+), 45 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 971d65c..565ac89 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -536,7 +536,7 @@ int vectors_user_mapping(void)
 	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
 				       VM_READ | VM_EXEC |
 				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
+				       VM_RESERVED,
 				       NULL);
 }
 
diff --git a/arch/hexagon/kernel/vdso.c b/arch/hexagon/kernel/vdso.c
index 16277c3..f212a45 100644
--- a/arch/hexagon/kernel/vdso.c
+++ b/arch/hexagon/kernel/vdso.c
@@ -78,8 +78,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	/* MAYWRITE to allow gdb to COW and set breakpoints. */
 	ret = install_special_mapping(mm, vdso_base, PAGE_SIZE,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      &vdso_page);
 
 	if (ret)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index e5cdfd6..0f1af58 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -88,8 +88,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, PAGE_SIZE,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      &vdso_page);
 
 	if (ret)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 7d14bb6..af58021 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -272,8 +272,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 */
 	rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 				     VM_READ|VM_EXEC|
-				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				     VM_ALWAYSDUMP,
+				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc) {
 		current->mm->context.vdso_base = 0;
diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index d73630b..25c838c 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -262,8 +262,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 */
 	rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 				     VM_READ|VM_EXEC|
-				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				     VM_ALWAYSDUMP,
+				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc)
 		current->mm->context.vdso_base = 0;
diff --git a/arch/sh/kernel/vsyscall/vsyscall.c b/arch/sh/kernel/vsyscall/vsyscall.c
index 1d6d51a..5ca5797 100644
--- a/arch/sh/kernel/vsyscall/vsyscall.c
+++ b/arch/sh/kernel/vsyscall/vsyscall.c
@@ -73,8 +73,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, PAGE_SIZE,
 				      VM_READ | VM_EXEC |
-				      VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC |
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
 				      syscall_pages);
 	if (unlikely(ret))
 		goto up_fail;
diff --git a/arch/tile/mm/elf.c b/arch/tile/mm/elf.c
index 55e58e9..c4b3ed8 100644
--- a/arch/tile/mm/elf.c
+++ b/arch/tile/mm/elf.c
@@ -126,8 +126,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 	vdso_base = VDSO_BASE;
 	retval = install_special_mapping(mm, vdso_base, PAGE_SIZE,
 					 VM_READ|VM_EXEC|
-					 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-					 VM_ALWAYSDUMP,
+					 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 					 vdso_pages);
 
 #ifndef __tilegx__
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index 52edc2b..432b429 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -381,7 +381,7 @@ int vectors_user_mapping(void)
 	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
 				       VM_READ | VM_EXEC |
 				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
+				       VM_RESERVED,
 				       NULL);
 }
 
diff --git a/arch/x86/um/mem_32.c b/arch/x86/um/mem_32.c
index 639900a..f40281e 100644
--- a/arch/x86/um/mem_32.c
+++ b/arch/x86/um/mem_32.c
@@ -23,14 +23,6 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
 
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
-
 	return 0;
 }
 __initcall(gate_vma_init);
diff --git a/arch/x86/um/vdso/vma.c b/arch/x86/um/vdso/vma.c
index 91f4ec9..af91901 100644
--- a/arch/x86/um/vdso/vma.c
+++ b/arch/x86/um/vdso/vma.c
@@ -64,8 +64,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	err = install_special_mapping(mm, um_vdso_addr, PAGE_SIZE,
 		VM_READ|VM_EXEC|
-		VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-		VM_ALWAYSDUMP,
+		VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 		vdsop);
 
 	up_write(&mm->mmap_sem);
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 468d591..b4d43dd 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -250,13 +250,7 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
+
 	return 0;
 }
 
@@ -352,8 +346,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 		 */
 		ret = install_special_mapping(mm, addr, PAGE_SIZE,
 					      VM_READ|VM_EXEC|
-					      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-					      VM_ALWAYSDUMP,
+					      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 					      vdso32_pages);
 
 		if (ret)
diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index 153407c..17e1827 100644
--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -124,8 +124,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, vdso_size,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      vdso_pages);
 	if (ret) {
 		current->mm->context.vdso = NULL;
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 07d096c..8a90861 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1094,6 +1094,24 @@ out:
  * Jeremy Fitzhardinge <jeremy@sw.oz.au>
  */
 
+/* Determine if the vma should always be output in the coredump */
+static bool always_dump_vma(struct vm_area_struct *vma)
+{
+	const char *vma_name = arch_vma_name(vma);
+
+	if (vma_name) {
+#ifdef CONFIG_TILE
+		/* Tile user-interrupt mapping which we don't always dump */
+		if (is_arch_mappable_range(vma->vm_start, 0))
+			return false;
+#endif
+		return true;
+	}
+	if (vma == get_gate_vma(vma->vm_mm))
+		return true;
+	return false;
+}
+
 /*
  * Decide what to dump of a segment, part, all or none.
  */
@@ -1102,8 +1120,8 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma,
 {
 #define FILTER(type)	(mm_flags & (1UL << MMF_DUMP_##type))
 
-	/* The vma can be set up to tell us the answer directly.  */
-	if (vma->vm_flags & VM_ALWAYSDUMP)
+	/* always dump the vdso and vsyscall sections */
+	if (always_dump_vma(vma))
 		goto whole;
 
 	/* Hugetlb memory check */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 17b27cd..a296709 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -111,7 +111,6 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_HUGEPAGE	0x01000000	/* MADV_HUGEPAGE marked this vma */
 #endif
 #define VM_INSERTPAGE	0x02000000	/* The vma has had "vm_insert_page()" done on it */
-#define VM_ALWAYSDUMP	0x04000000	/* Always include in core dumps */
 
 #define VM_CAN_NONLINEAR 0x08000000	/* Has ->fault & does nonlinear pages */
 #define VM_MIXEDMAP	0x10000000	/* Can contain "struct page" and pure PFN pages */
diff --git a/mm/memory.c b/mm/memory.c
index fa2f04e..9b55ab0 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3611,13 +3611,7 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
+
 	return 0;
 }
 __initcall(gate_vma_init);
-- 
1.7.7.6


^ permalink raw reply related	[flat|nested] 30+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
@ 2012-03-07 21:19           ` Jason Baron
  0 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 21:19 UTC (permalink / raw)
  To: Roland McGrath; +Cc: qemu-devel, akpm, avi, cmetcalf, linux-kernel

On Wed, Mar 07, 2012 at 11:43:02AM -0800, Roland McGrath wrote:
> > well, sure, we can provide an arch interface, for this check. I'm more
> > concerned with the general idea. If it seems ok, I can re-do this bit
> > with an arch interface.
> 
> Anything based on strcmp is dismal.  VM_ALWAYSDUMP was nice and clean.
> A hook along the lines of arch_vma_name would be clean enough I suppose.
> In fact, there is only one instance today (tile) where arch_vma_name()!=NULL
> wouldn't do just what you need.
> 

Yeah, so I think something like the following would work (adding Tile
maintainer to 'cc list).

Thanks,

-Jason



The VM_ALWAYSDUMP flag is currently used by the coredump code to indicate that
a vma is part of a vsyscall or vdso section, and then always dump it. However, we
can determine if a vma is in one of these sections by using 'arch_vma_name()',
and thus re-purpose a valuable vma bit.

Signed-off-by: Jason Baron <jbaron@redhat.com>
---
 arch/arm/kernel/process.c          |    2 +-
 arch/hexagon/kernel/vdso.c         |    3 +--
 arch/mips/kernel/vdso.c            |    3 +--
 arch/powerpc/kernel/vdso.c         |    3 +--
 arch/s390/kernel/vdso.c            |    3 +--
 arch/sh/kernel/vsyscall/vsyscall.c |    3 +--
 arch/tile/mm/elf.c                 |    3 +--
 arch/unicore32/kernel/process.c    |    2 +-
 arch/x86/um/mem_32.c               |    8 --------
 arch/x86/um/vdso/vma.c             |    3 +--
 arch/x86/vdso/vdso32-setup.c       |   11 ++---------
 arch/x86/vdso/vma.c                |    3 +--
 fs/binfmt_elf.c                    |   22 ++++++++++++++++++++--
 include/linux/mm.h                 |    1 -
 mm/memory.c                        |    8 +-------
 15 files changed, 33 insertions(+), 45 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 971d65c..565ac89 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -536,7 +536,7 @@ int vectors_user_mapping(void)
 	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
 				       VM_READ | VM_EXEC |
 				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
+				       VM_RESERVED,
 				       NULL);
 }
 
diff --git a/arch/hexagon/kernel/vdso.c b/arch/hexagon/kernel/vdso.c
index 16277c3..f212a45 100644
--- a/arch/hexagon/kernel/vdso.c
+++ b/arch/hexagon/kernel/vdso.c
@@ -78,8 +78,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	/* MAYWRITE to allow gdb to COW and set breakpoints. */
 	ret = install_special_mapping(mm, vdso_base, PAGE_SIZE,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      &vdso_page);
 
 	if (ret)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index e5cdfd6..0f1af58 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -88,8 +88,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, PAGE_SIZE,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      &vdso_page);
 
 	if (ret)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 7d14bb6..af58021 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -272,8 +272,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 */
 	rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 				     VM_READ|VM_EXEC|
-				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				     VM_ALWAYSDUMP,
+				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc) {
 		current->mm->context.vdso_base = 0;
diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index d73630b..25c838c 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -262,8 +262,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 */
 	rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 				     VM_READ|VM_EXEC|
-				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				     VM_ALWAYSDUMP,
+				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc)
 		current->mm->context.vdso_base = 0;
diff --git a/arch/sh/kernel/vsyscall/vsyscall.c b/arch/sh/kernel/vsyscall/vsyscall.c
index 1d6d51a..5ca5797 100644
--- a/arch/sh/kernel/vsyscall/vsyscall.c
+++ b/arch/sh/kernel/vsyscall/vsyscall.c
@@ -73,8 +73,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, PAGE_SIZE,
 				      VM_READ | VM_EXEC |
-				      VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC |
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
 				      syscall_pages);
 	if (unlikely(ret))
 		goto up_fail;
diff --git a/arch/tile/mm/elf.c b/arch/tile/mm/elf.c
index 55e58e9..c4b3ed8 100644
--- a/arch/tile/mm/elf.c
+++ b/arch/tile/mm/elf.c
@@ -126,8 +126,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 	vdso_base = VDSO_BASE;
 	retval = install_special_mapping(mm, vdso_base, PAGE_SIZE,
 					 VM_READ|VM_EXEC|
-					 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-					 VM_ALWAYSDUMP,
+					 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 					 vdso_pages);
 
 #ifndef __tilegx__
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index 52edc2b..432b429 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -381,7 +381,7 @@ int vectors_user_mapping(void)
 	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
 				       VM_READ | VM_EXEC |
 				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
+				       VM_RESERVED,
 				       NULL);
 }
 
diff --git a/arch/x86/um/mem_32.c b/arch/x86/um/mem_32.c
index 639900a..f40281e 100644
--- a/arch/x86/um/mem_32.c
+++ b/arch/x86/um/mem_32.c
@@ -23,14 +23,6 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
 
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
-
 	return 0;
 }
 __initcall(gate_vma_init);
diff --git a/arch/x86/um/vdso/vma.c b/arch/x86/um/vdso/vma.c
index 91f4ec9..af91901 100644
--- a/arch/x86/um/vdso/vma.c
+++ b/arch/x86/um/vdso/vma.c
@@ -64,8 +64,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	err = install_special_mapping(mm, um_vdso_addr, PAGE_SIZE,
 		VM_READ|VM_EXEC|
-		VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-		VM_ALWAYSDUMP,
+		VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 		vdsop);
 
 	up_write(&mm->mmap_sem);
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 468d591..b4d43dd 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -250,13 +250,7 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
+
 	return 0;
 }
 
@@ -352,8 +346,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 		 */
 		ret = install_special_mapping(mm, addr, PAGE_SIZE,
 					      VM_READ|VM_EXEC|
-					      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-					      VM_ALWAYSDUMP,
+					      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 					      vdso32_pages);
 
 		if (ret)
diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index 153407c..17e1827 100644
--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -124,8 +124,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 	ret = install_special_mapping(mm, addr, vdso_size,
 				      VM_READ|VM_EXEC|
-				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
-				      VM_ALWAYSDUMP,
+				      VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				      vdso_pages);
 	if (ret) {
 		current->mm->context.vdso = NULL;
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 07d096c..8a90861 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1094,6 +1094,24 @@ out:
  * Jeremy Fitzhardinge <jeremy@sw.oz.au>
  */
 
+/* Determine if the vma should always be output in the coredump */
+static bool always_dump_vma(struct vm_area_struct *vma)
+{
+	const char *vma_name = arch_vma_name(vma);
+
+	if (vma_name) {
+#ifdef CONFIG_TILE
+		/* Tile user-interrupt mapping which we don't always dump */
+		if (is_arch_mappable_range(vma->vm_start, 0))
+			return false;
+#endif
+		return true;
+	}
+	if (vma == get_gate_vma(vma->vm_mm))
+		return true;
+	return false;
+}
+
 /*
  * Decide what to dump of a segment, part, all or none.
  */
@@ -1102,8 +1120,8 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma,
 {
 #define FILTER(type)	(mm_flags & (1UL << MMF_DUMP_##type))
 
-	/* The vma can be set up to tell us the answer directly.  */
-	if (vma->vm_flags & VM_ALWAYSDUMP)
+	/* always dump the vdso and vsyscall sections */
+	if (always_dump_vma(vma))
 		goto whole;
 
 	/* Hugetlb memory check */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 17b27cd..a296709 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -111,7 +111,6 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_HUGEPAGE	0x01000000	/* MADV_HUGEPAGE marked this vma */
 #endif
 #define VM_INSERTPAGE	0x02000000	/* The vma has had "vm_insert_page()" done on it */
-#define VM_ALWAYSDUMP	0x04000000	/* Always include in core dumps */
 
 #define VM_CAN_NONLINEAR 0x08000000	/* Has ->fault & does nonlinear pages */
 #define VM_MIXEDMAP	0x10000000	/* Can contain "struct page" and pure PFN pages */
diff --git a/mm/memory.c b/mm/memory.c
index fa2f04e..9b55ab0 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3611,13 +3611,7 @@ static int __init gate_vma_init(void)
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
 	gate_vma.vm_page_prot = __P101;
-	/*
-	 * Make sure the vDSO gets into every core dump.
-	 * Dumping its contents makes post-mortem fully interpretable later
-	 * without matching up the same kernel and hardware config to see
-	 * what PC values meant.
-	 */
-	gate_vma.vm_flags |= VM_ALWAYSDUMP;
+
 	return 0;
 }
 __initcall(gate_vma_init);
-- 
1.7.7.6

^ permalink raw reply related	[flat|nested] 30+ messages in thread

* Re: [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
  2012-03-07 21:19           ` [Qemu-devel] " Jason Baron
@ 2012-03-07 21:26             ` Chris Metcalf
  -1 siblings, 0 replies; 30+ messages in thread
From: Chris Metcalf @ 2012-03-07 21:26 UTC (permalink / raw)
  To: Jason Baron; +Cc: Roland McGrath, akpm, avi, linux-kernel, qemu-devel

On 3/7/2012 4:19 PM, Jason Baron wrote:
> On Wed, Mar 07, 2012 at 11:43:02AM -0800, Roland McGrath wrote:
>>> well, sure, we can provide an arch interface, for this check. I'm more
>>> concerned with the general idea. If it seems ok, I can re-do this bit
>>> with an arch interface.
>> Anything based on strcmp is dismal.  VM_ALWAYSDUMP was nice and clean.
>> A hook along the lines of arch_vma_name would be clean enough I suppose.
>> In fact, there is only one instance today (tile) where arch_vma_name()!=NULL
>> wouldn't do just what you need.
>>
> Yeah, so I think something like the following would work (adding Tile
> maintainer to 'cc list).

Thanks!

My instinct would be not to special-case it in always_dump_vma().  Since
it's just a one-page region anyway, and it is at least potentially
interesting, I'm happy to always dump it.  Alternately, we can just get rid
of the "[intrpt]" name, which I just put in to be cute (and since it was
easy to identify the mapping in question).  Regardless, since that region
doesn't exist on our current 64-bit architecture, I'm not too concerned
with how it's handled going forward, since I expect the 32-bit platform to
become less popular over time.  I'd vote for generic code cleanliness.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
@ 2012-03-07 21:26             ` Chris Metcalf
  0 siblings, 0 replies; 30+ messages in thread
From: Chris Metcalf @ 2012-03-07 21:26 UTC (permalink / raw)
  To: Jason Baron; +Cc: qemu-devel, linux-kernel, akpm, avi, Roland McGrath

On 3/7/2012 4:19 PM, Jason Baron wrote:
> On Wed, Mar 07, 2012 at 11:43:02AM -0800, Roland McGrath wrote:
>>> well, sure, we can provide an arch interface, for this check. I'm more
>>> concerned with the general idea. If it seems ok, I can re-do this bit
>>> with an arch interface.
>> Anything based on strcmp is dismal.  VM_ALWAYSDUMP was nice and clean.
>> A hook along the lines of arch_vma_name would be clean enough I suppose.
>> In fact, there is only one instance today (tile) where arch_vma_name()!=NULL
>> wouldn't do just what you need.
>>
> Yeah, so I think something like the following would work (adding Tile
> maintainer to 'cc list).

Thanks!

My instinct would be not to special-case it in always_dump_vma().  Since
it's just a one-page region anyway, and it is at least potentially
interesting, I'm happy to always dump it.  Alternately, we can just get rid
of the "[intrpt]" name, which I just put in to be cute (and since it was
easy to identify the mapping in question).  Regardless, since that region
doesn't exist on our current 64-bit architecture, I'm not too concerned
with how it's handled going forward, since I expect the 32-bit platform to
become less popular over time.  I'd vote for generic code cleanliness.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
  2012-03-07 21:26             ` [Qemu-devel] " Chris Metcalf
@ 2012-03-07 21:36               ` Jason Baron
  -1 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 21:36 UTC (permalink / raw)
  To: Chris Metcalf; +Cc: Roland McGrath, akpm, avi, linux-kernel, qemu-devel

On Wed, Mar 07, 2012 at 04:26:46PM -0500, Chris Metcalf wrote:
> On 3/7/2012 4:19 PM, Jason Baron wrote:
> > On Wed, Mar 07, 2012 at 11:43:02AM -0800, Roland McGrath wrote:
> >>> well, sure, we can provide an arch interface, for this check. I'm more
> >>> concerned with the general idea. If it seems ok, I can re-do this bit
> >>> with an arch interface.
> >> Anything based on strcmp is dismal.  VM_ALWAYSDUMP was nice and clean.
> >> A hook along the lines of arch_vma_name would be clean enough I suppose.
> >> In fact, there is only one instance today (tile) where arch_vma_name()!=NULL
> >> wouldn't do just what you need.
> >>
> > Yeah, so I think something like the following would work (adding Tile
> > maintainer to 'cc list).
> 
> Thanks!
> 
> My instinct would be not to special-case it in always_dump_vma().  Since
> it's just a one-page region anyway, and it is at least potentially
> interesting, I'm happy to always dump it.  Alternately, we can just get rid
> of the "[intrpt]" name, which I just put in to be cute (and since it was
> easy to identify the mapping in question).  Regardless, since that region
> doesn't exist on our current 64-bit architecture, I'm not too concerned
> with how it's handled going forward, since I expect the 32-bit platform to
> become less popular over time.  I'd vote for generic code cleanliness.
> 

Ok, I'll just always dump it.

Thanks!

-Jason

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
@ 2012-03-07 21:36               ` Jason Baron
  0 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-07 21:36 UTC (permalink / raw)
  To: Chris Metcalf; +Cc: qemu-devel, linux-kernel, akpm, avi, Roland McGrath

On Wed, Mar 07, 2012 at 04:26:46PM -0500, Chris Metcalf wrote:
> On 3/7/2012 4:19 PM, Jason Baron wrote:
> > On Wed, Mar 07, 2012 at 11:43:02AM -0800, Roland McGrath wrote:
> >>> well, sure, we can provide an arch interface, for this check. I'm more
> >>> concerned with the general idea. If it seems ok, I can re-do this bit
> >>> with an arch interface.
> >> Anything based on strcmp is dismal.  VM_ALWAYSDUMP was nice and clean.
> >> A hook along the lines of arch_vma_name would be clean enough I suppose.
> >> In fact, there is only one instance today (tile) where arch_vma_name()!=NULL
> >> wouldn't do just what you need.
> >>
> > Yeah, so I think something like the following would work (adding Tile
> > maintainer to 'cc list).
> 
> Thanks!
> 
> My instinct would be not to special-case it in always_dump_vma().  Since
> it's just a one-page region anyway, and it is at least potentially
> interesting, I'm happy to always dump it.  Alternately, we can just get rid
> of the "[intrpt]" name, which I just put in to be cute (and since it was
> easy to identify the mapping in question).  Regardless, since that region
> doesn't exist on our current 64-bit architecture, I'm not too concerned
> with how it's handled going forward, since I expect the 32-bit platform to
> become less popular over time.  I'd vote for generic code cleanliness.
> 

Ok, I'll just always dump it.

Thanks!

-Jason

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
  2012-03-07 21:19           ` [Qemu-devel] " Jason Baron
@ 2012-03-07 21:41             ` Roland McGrath
  -1 siblings, 0 replies; 30+ messages in thread
From: Roland McGrath @ 2012-03-07 21:41 UTC (permalink / raw)
  To: Jason Baron; +Cc: akpm, avi, linux-kernel, qemu-devel, cmetcalf

A few of the vDSO VM_ALWAYSDUMP cases have a comment about the core dump.
(It looks like they were all copied from my original comment in
arch/x86/vdso/vdso32-setup.c.)  So those should be removed where they are.
(You removed some of them, but not all.)  You should put that comment into
always_dump_vma.

get_gate_vma is always defined quite trivially, and is also the most
logically obvious case, so I would test it first.

It sounds like the Tile special case is unnecessary, so just
arch_vma_name(vma) != NULL is an adequate test.  Please give it
a clear comment about why that test makes sense, i.e. because all
extant uses are for a vDSO or something similar.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag
@ 2012-03-07 21:41             ` Roland McGrath
  0 siblings, 0 replies; 30+ messages in thread
From: Roland McGrath @ 2012-03-07 21:41 UTC (permalink / raw)
  To: Jason Baron; +Cc: qemu-devel, akpm, avi, cmetcalf, linux-kernel

A few of the vDSO VM_ALWAYSDUMP cases have a comment about the core dump.
(It looks like they were all copied from my original comment in
arch/x86/vdso/vdso32-setup.c.)  So those should be removed where they are.
(You removed some of them, but not all.)  You should put that comment into
always_dump_vma.

get_gate_vma is always defined quite trivially, and is also the most
logically obvious case, so I would test it first.

It sounds like the Tile special case is unnecessary, so just
arch_vma_name(vma) != NULL is an adequate test.  Please give it
a clear comment about why that test makes sense, i.e. because all
extant uses are for a vDSO or something similar.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
  2012-03-07 17:00 ` [Qemu-devel] " Jason Baron
@ 2012-03-07 22:30   ` Andrew Morton
  -1 siblings, 0 replies; 30+ messages in thread
From: Andrew Morton @ 2012-03-07 22:30 UTC (permalink / raw)
  To: Jason Baron; +Cc: mcgrathr, avi, linux-kernel, qemu-devel

On Wed, 7 Mar 2012 12:00:46 -0500
Jason Baron <jbaron@redhat.com> wrote:

> Hi,
> 
> The motivation for this change was that I was looking at a way for a qemu-kvm
> process, to exclude the guest memory from its core dump, which can be quite
> large. There are already a number of filter flags in
> /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
> kernel memory, not specific address ranges (which is needed in this case).
> 
> Since there are no more vma flags available, the first patch eliminates the
> need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
> mark vdso and vsyscall pages. However, it is simple enough to check if a vma
> covers a vdso or vsyscall page without the need for this flag.

Gee, we ran out?

That makes it pretty inevitable that we will grow the vma by four
bytes.  Once we have done that, your always_dump_vma() trickery becomes
unneeded and undesirable, yes?  If so, we may as well recognise reality
and grow the vma now.

> The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new 
> 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
> 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
> work the same as before unless 'MADV_DONTDUMP' is set on the region.
> 
> The qemu code which implements this features is at:
> http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
> 
> In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
> 
> I also believe that the 'MADV_DONTDUMP' flag might be useful for security
> sensitive apps, which might want to select which areas are dumped.
> 

Is there any way for userspace to query the state of the flag?  


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [Qemu-devel] [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
@ 2012-03-07 22:30   ` Andrew Morton
  0 siblings, 0 replies; 30+ messages in thread
From: Andrew Morton @ 2012-03-07 22:30 UTC (permalink / raw)
  To: Jason Baron; +Cc: qemu-devel, linux-kernel, mcgrathr, avi

On Wed, 7 Mar 2012 12:00:46 -0500
Jason Baron <jbaron@redhat.com> wrote:

> Hi,
> 
> The motivation for this change was that I was looking at a way for a qemu-kvm
> process, to exclude the guest memory from its core dump, which can be quite
> large. There are already a number of filter flags in
> /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
> kernel memory, not specific address ranges (which is needed in this case).
> 
> Since there are no more vma flags available, the first patch eliminates the
> need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
> mark vdso and vsyscall pages. However, it is simple enough to check if a vma
> covers a vdso or vsyscall page without the need for this flag.

Gee, we ran out?

That makes it pretty inevitable that we will grow the vma by four
bytes.  Once we have done that, your always_dump_vma() trickery becomes
unneeded and undesirable, yes?  If so, we may as well recognise reality
and grow the vma now.

> The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new 
> 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
> 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
> work the same as before unless 'MADV_DONTDUMP' is set on the region.
> 
> The qemu code which implements this features is at:
> http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
> 
> In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
> 
> I also believe that the 'MADV_DONTDUMP' flag might be useful for security
> sensitive apps, which might want to select which areas are dumped.
> 

Is there any way for userspace to query the state of the flag?  

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
  2012-03-07 22:30   ` [Qemu-devel] " Andrew Morton
@ 2012-03-08  1:32     ` Jason Baron
  -1 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-08  1:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: mcgrathr, avi, linux-kernel, qemu-devel

On Wed, Mar 07, 2012 at 02:30:28PM -0800, Andrew Morton wrote:
> On Wed, 7 Mar 2012 12:00:46 -0500
> Jason Baron <jbaron@redhat.com> wrote:
> 
> > Hi,
> > 
> > The motivation for this change was that I was looking at a way for a qemu-kvm
> > process, to exclude the guest memory from its core dump, which can be quite
> > large. There are already a number of filter flags in
> > /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
> > kernel memory, not specific address ranges (which is needed in this case).
> > 
> > Since there are no more vma flags available, the first patch eliminates the
> > need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
> > mark vdso and vsyscall pages. However, it is simple enough to check if a vma
> > covers a vdso or vsyscall page without the need for this flag.
> 
> Gee, we ran out?
> 
> That makes it pretty inevitable that we will grow the vma by four
> bytes.  Once we have done that, your always_dump_vma() trickery becomes
> unneeded and undesirable, yes?  If so, we may as well recognise reality
> and grow the vma now.
> 

We could. The reason I didn't propose increasing them was because I saw
in the archives that there was resistance when this was tried before:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.1/02053.html

Also, the current use of 'VM_ALWAYSDUMP' is for vdso and gate pages
exclusively. That means that VM_ALWAYSDUMP flag is 0 the majority of the
time, and thus it probably makes sense to re-purpose it, now that we are
tight on flags.

> > The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new 
> > 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
> > 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
> > work the same as before unless 'MADV_DONTDUMP' is set on the region.
> > 
> > The qemu code which implements this features is at:
> > http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
> > 
> > In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
> > 
> > I also believe that the 'MADV_DONTDUMP' flag might be useful for security
> > sensitive apps, which might want to select which areas are dumped.
> > 
> 
> Is there any way for userspace to query the state of the flag?  
> 

A place for that might be /proc/<pid>/maps, but I don't think any of
the other vm flags are exposed.

Thanks,

-Jason

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [Qemu-devel] [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
@ 2012-03-08  1:32     ` Jason Baron
  0 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-03-08  1:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: qemu-devel, linux-kernel, mcgrathr, avi

On Wed, Mar 07, 2012 at 02:30:28PM -0800, Andrew Morton wrote:
> On Wed, 7 Mar 2012 12:00:46 -0500
> Jason Baron <jbaron@redhat.com> wrote:
> 
> > Hi,
> > 
> > The motivation for this change was that I was looking at a way for a qemu-kvm
> > process, to exclude the guest memory from its core dump, which can be quite
> > large. There are already a number of filter flags in
> > /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
> > kernel memory, not specific address ranges (which is needed in this case).
> > 
> > Since there are no more vma flags available, the first patch eliminates the
> > need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
> > mark vdso and vsyscall pages. However, it is simple enough to check if a vma
> > covers a vdso or vsyscall page without the need for this flag.
> 
> Gee, we ran out?
> 
> That makes it pretty inevitable that we will grow the vma by four
> bytes.  Once we have done that, your always_dump_vma() trickery becomes
> unneeded and undesirable, yes?  If so, we may as well recognise reality
> and grow the vma now.
> 

We could. The reason I didn't propose increasing them was because I saw
in the archives that there was resistance when this was tried before:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.1/02053.html

Also, the current use of 'VM_ALWAYSDUMP' is for vdso and gate pages
exclusively. That means that VM_ALWAYSDUMP flag is 0 the majority of the
time, and thus it probably makes sense to re-purpose it, now that we are
tight on flags.

> > The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new 
> > 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
> > 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
> > work the same as before unless 'MADV_DONTDUMP' is set on the region.
> > 
> > The qemu code which implements this features is at:
> > http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
> > 
> > In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
> > 
> > I also believe that the 'MADV_DONTDUMP' flag might be useful for security
> > sensitive apps, which might want to select which areas are dumped.
> > 
> 
> Is there any way for userspace to query the state of the flag?  
> 

A place for that might be /proc/<pid>/maps, but I don't think any of
the other vm flags are exposed.

Thanks,

-Jason

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
@ 2012-04-23 22:42   ` Michael Kerrisk
  0 siblings, 0 replies; 30+ messages in thread
From: Michael Kerrisk @ 2012-04-23 22:42 UTC (permalink / raw)
  To: Jason Baron
  Cc: mcgrathr, akpm, avi, linux-kernel, qemu-devel, Michael Kerrisk,
	Linux API

Jason,

On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron <jbaron@redhat.com> wrote:
> Hi,
>
> The motivation for this change was that I was looking at a way for a qemu-kvm
> process, to exclude the guest memory from its core dump, which can be quite
> large. There are already a number of filter flags in
> /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
> kernel memory, not specific address ranges (which is needed in this case).
>
> Since there are no more vma flags available, the first patch eliminates the
> need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
> mark vdso and vsyscall pages. However, it is simple enough to check if a vma
> covers a vdso or vsyscall page without the need for this flag.
>
> The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
> 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
> 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
> work the same as before unless 'MADV_DONTDUMP' is set on the region.
>
> The qemu code which implements this features is at:
> http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
>
> In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
>
> I also believe that the 'MADV_DONTDUMP' flag might be useful for security
> sensitive apps, which might want to select which areas are dumped.

Since we have
MADV_DODUMP
MADV_DONTDUMP
MADV_NODUMP
heading for userspace in 3.4, would you be willing to write patches
for the madvise(2) man page to describe these flags?

See http://www.kernel.org/doc/man-pages/download.html for details on
accessing man-pages Git.

Cheers,

Michael

PS Please also CC linux-api@ when making API/ABI changes.


-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
@ 2012-04-23 22:42   ` Michael Kerrisk
  0 siblings, 0 replies; 30+ messages in thread
From: Michael Kerrisk @ 2012-04-23 22:42 UTC (permalink / raw)
  To: Jason Baron
  Cc: mcgrathr-hpIqsD4AKlfQT0dZR+AlfA,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	avi-H+wXaHxf7aLQT0dZR+AlfA, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	qemu-devel-qX2TKyscuCcdnm+yROfE0A, Michael Kerrisk, Linux API

Jason,

On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron <jbaron-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Hi,
>
> The motivation for this change was that I was looking at a way for a qemu-kvm
> process, to exclude the guest memory from its core dump, which can be quite
> large. There are already a number of filter flags in
> /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
> kernel memory, not specific address ranges (which is needed in this case).
>
> Since there are no more vma flags available, the first patch eliminates the
> need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
> mark vdso and vsyscall pages. However, it is simple enough to check if a vma
> covers a vdso or vsyscall page without the need for this flag.
>
> The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
> 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
> 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
> work the same as before unless 'MADV_DONTDUMP' is set on the region.
>
> The qemu code which implements this features is at:
> http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
>
> In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
>
> I also believe that the 'MADV_DONTDUMP' flag might be useful for security
> sensitive apps, which might want to select which areas are dumped.

Since we have
MADV_DODUMP
MADV_DONTDUMP
MADV_NODUMP
heading for userspace in 3.4, would you be willing to write patches
for the madvise(2) man page to describe these flags?

See http://www.kernel.org/doc/man-pages/download.html for details on
accessing man-pages Git.

Cheers,

Michael

PS Please also CC linux-api@ when making API/ABI changes.


-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
  2012-04-23 22:42   ` Michael Kerrisk
@ 2012-04-27 18:43     ` Jason Baron
  -1 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-04-27 18:43 UTC (permalink / raw)
  To: Michael Kerrisk; +Cc: mcgrathr, akpm, avi, linux-kernel, qemu-devel, Linux API

On Tue, Apr 24, 2012 at 10:42:16AM +1200, Michael Kerrisk wrote:
> Jason,
> 
> On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron <jbaron@redhat.com> wrote:
> > Hi,
> >
> > The motivation for this change was that I was looking at a way for a qemu-kvm
> > process, to exclude the guest memory from its core dump, which can be quite
> > large. There are already a number of filter flags in
> > /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
> > kernel memory, not specific address ranges (which is needed in this case).
> >
> > Since there are no more vma flags available, the first patch eliminates the
> > need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
> > mark vdso and vsyscall pages. However, it is simple enough to check if a vma
> > covers a vdso or vsyscall page without the need for this flag.
> >
> > The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
> > 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
> > 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
> > work the same as before unless 'MADV_DONTDUMP' is set on the region.
> >
> > The qemu code which implements this features is at:
> > http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
> >
> > In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
> >
> > I also believe that the 'MADV_DONTDUMP' flag might be useful for security
> > sensitive apps, which might want to select which areas are dumped.
> 
> Since we have
> MADV_DODUMP
> MADV_DONTDUMP
> MADV_NODUMP
> heading for userspace in 3.4, would you be willing to write patches
> for the madvise(2) man page to describe these flags?
> 
> See http://www.kernel.org/doc/man-pages/download.html for details on
> accessing man-pages Git.
> 
> Cheers,
> 
> Michael
> 
> PS Please also CC linux-api@ when making API/ABI changes.
> 

Ok, here's a stab at manpage patch, let me know if I should send it as a
separate patch. Thanks.

-Jason


diff --git a/man2/madvise.2 b/man2/madvise.2
index 36f988a..472c23a 100644
--- a/man2/madvise.2
+++ b/man2/madvise.2
@@ -247,6 +247,22 @@ Ensures that memory in the address range specified by
 and
 .IR length
 will not be collapsed into huge pages.
+.TP
+.BR MADV_DONTDUMP " (since Linux 3.4)"
+Explicitly exclude from a core dump those pages in the range specified by
+.I addr
+and
+.IR length .
+Applications may have large areas of memory which are known not to be useful in
+diagnosing a core dump. This specification takes precedence over the bit mask that
+is set via the
+.I /proc/PID/coredump_filter
+file (see
+.BR core (5)).
+.TP
+.BR MADV_DODUMP " (since Linux 3.4)"
+Undo the effect of an earlier
+.BR MADV_DONTDUMP.
 .SH "RETURN VALUE"
 On success
 .BR madvise ()
@@ -356,4 +372,5 @@ from the system call, as it should).
 .BR mmap (2),
 .BR mprotect (2),
 .BR msync (2),
-.BR munmap (2)
+.BR munmap (2),
+.BR core (5)

^ permalink raw reply related	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
@ 2012-04-27 18:43     ` Jason Baron
  0 siblings, 0 replies; 30+ messages in thread
From: Jason Baron @ 2012-04-27 18:43 UTC (permalink / raw)
  To: Michael Kerrisk; +Cc: mcgrathr, Linux API, qemu-devel, linux-kernel, avi, akpm

On Tue, Apr 24, 2012 at 10:42:16AM +1200, Michael Kerrisk wrote:
> Jason,
> 
> On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron <jbaron@redhat.com> wrote:
> > Hi,
> >
> > The motivation for this change was that I was looking at a way for a qemu-kvm
> > process, to exclude the guest memory from its core dump, which can be quite
> > large. There are already a number of filter flags in
> > /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
> > kernel memory, not specific address ranges (which is needed in this case).
> >
> > Since there are no more vma flags available, the first patch eliminates the
> > need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
> > mark vdso and vsyscall pages. However, it is simple enough to check if a vma
> > covers a vdso or vsyscall page without the need for this flag.
> >
> > The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
> > 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
> > 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
> > work the same as before unless 'MADV_DONTDUMP' is set on the region.
> >
> > The qemu code which implements this features is at:
> > http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
> >
> > In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
> >
> > I also believe that the 'MADV_DONTDUMP' flag might be useful for security
> > sensitive apps, which might want to select which areas are dumped.
> 
> Since we have
> MADV_DODUMP
> MADV_DONTDUMP
> MADV_NODUMP
> heading for userspace in 3.4, would you be willing to write patches
> for the madvise(2) man page to describe these flags?
> 
> See http://www.kernel.org/doc/man-pages/download.html for details on
> accessing man-pages Git.
> 
> Cheers,
> 
> Michael
> 
> PS Please also CC linux-api@ when making API/ABI changes.
> 

Ok, here's a stab at manpage patch, let me know if I should send it as a
separate patch. Thanks.

-Jason


diff --git a/man2/madvise.2 b/man2/madvise.2
index 36f988a..472c23a 100644
--- a/man2/madvise.2
+++ b/man2/madvise.2
@@ -247,6 +247,22 @@ Ensures that memory in the address range specified by
 and
 .IR length
 will not be collapsed into huge pages.
+.TP
+.BR MADV_DONTDUMP " (since Linux 3.4)"
+Explicitly exclude from a core dump those pages in the range specified by
+.I addr
+and
+.IR length .
+Applications may have large areas of memory which are known not to be useful in
+diagnosing a core dump. This specification takes precedence over the bit mask that
+is set via the
+.I /proc/PID/coredump_filter
+file (see
+.BR core (5)).
+.TP
+.BR MADV_DODUMP " (since Linux 3.4)"
+Undo the effect of an earlier
+.BR MADV_DONTDUMP.
 .SH "RETURN VALUE"
 On success
 .BR madvise ()
@@ -356,4 +372,5 @@ from the system call, as it should).
 .BR mmap (2),
 .BR mprotect (2),
 .BR msync (2),
-.BR munmap (2)
+.BR munmap (2),
+.BR core (5)

^ permalink raw reply related	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
@ 2012-04-28  7:29       ` Michael Kerrisk (man-pages)
  0 siblings, 0 replies; 30+ messages in thread
From: Michael Kerrisk (man-pages) @ 2012-04-28  7:29 UTC (permalink / raw)
  To: Jason Baron; +Cc: mcgrathr, akpm, avi, linux-kernel, qemu-devel, Linux API

Hello Jason,

On Sat, Apr 28, 2012 at 6:43 AM, Jason Baron <jbaron@redhat.com> wrote:
> On Tue, Apr 24, 2012 at 10:42:16AM +1200, Michael Kerrisk wrote:
>> Jason,
>>
>> On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron <jbaron@redhat.com> wrote:
>> > Hi,
>> >
>> > The motivation for this change was that I was looking at a way for a qemu-kvm
>> > process, to exclude the guest memory from its core dump, which can be quite
>> > large. There are already a number of filter flags in
>> > /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
>> > kernel memory, not specific address ranges (which is needed in this case).
>> >
>> > Since there are no more vma flags available, the first patch eliminates the
>> > need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
>> > mark vdso and vsyscall pages. However, it is simple enough to check if a vma
>> > covers a vdso or vsyscall page without the need for this flag.
>> >
>> > The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
>> > 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
>> > 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
>> > work the same as before unless 'MADV_DONTDUMP' is set on the region.
>> >
>> > The qemu code which implements this features is at:
>> > http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
>> >
>> > In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
>> >
>> > I also believe that the 'MADV_DONTDUMP' flag might be useful for security
>> > sensitive apps, which might want to select which areas are dumped.
>>
>> Since we have
>> MADV_DODUMP
>> MADV_DONTDUMP
>> MADV_NODUMP
>> heading for userspace in 3.4, would you be willing to write patches
>> for the madvise(2) man page to describe these flags?
>>
>> See http://www.kernel.org/doc/man-pages/download.html for details on
>> accessing man-pages Git.
>>
>> Cheers,
>>
>> Michael
>>
>> PS Please also CC linux-api@ when making API/ABI changes.
>>
>
> Ok, here's a stab at manpage patch, let me know if I should send it as a
> separate patch. Thanks.
>
> -Jason
>
>
> diff --git a/man2/madvise.2 b/man2/madvise.2
> index 36f988a..472c23a 100644
> --- a/man2/madvise.2
> +++ b/man2/madvise.2
> @@ -247,6 +247,22 @@ Ensures that memory in the address range specified by
>  and
>  .IR length
>  will not be collapsed into huge pages.
> +.TP
> +.BR MADV_DONTDUMP " (since Linux 3.4)"
> +Explicitly exclude from a core dump those pages in the range specified by
> +.I addr
> +and
> +.IR length .
> +Applications may have large areas of memory which are known not to be useful in
> +diagnosing a core dump. This specification takes precedence over the bit mask that
> +is set via the
> +.I /proc/PID/coredump_filter
> +file (see
> +.BR core (5)).
> +.TP
> +.BR MADV_DODUMP " (since Linux 3.4)"
> +Undo the effect of an earlier
> +.BR MADV_DONTDUMP.
>  .SH "RETURN VALUE"
>  On success
>  .BR madvise ()
> @@ -356,4 +372,5 @@ from the system call, as it should).
>  .BR mmap (2),
>  .BR mprotect (2),
>  .BR msync (2),
> -.BR munmap (2)
> +.BR munmap (2),
> +.BR core (5)

Thanks! I tweaked this patch a little and applied the version below.

Cheers,

Michael

--- a/man2/madvise.2
+++ b/man2/madvise.2
@@ -247,6 +247,24 @@ Ensures that memory in the address range specified by
 and
 .IR length
 will not be collapsed into huge pages.
+.TP
+.BR MADV_DONTDUMP " (since Linux 3.4)"
+Exclude from a core dump those pages in the range specified by
+.I addr
+and
+.IR length .
+This is useful in applications that have large areas of memory
+that are known not to be useful in a core dump.
+The effect of
+.BR MADV_DONTDUMP
+takes precedence over the bit mask that is set via the
+.I /proc/PID/coredump_filter
+file (see
+.BR core (5)).
+.TP
+.BR MADV_DODUMP " (since Linux 3.4)"
+Undo the effect of an earlier
+.BR MADV_DONTDUMP .
 .SH "RETURN VALUE"
 On success
 .BR madvise ()
@@ -356,4 +374,5 @@ from the system call, as it should).
 .BR mmap (2),
 .BR mprotect (2),
 .BR msync (2),
-.BR munmap (2)
+.BR munmap (2),
+.BR core (5)

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
@ 2012-04-28  7:29       ` Michael Kerrisk (man-pages)
  0 siblings, 0 replies; 30+ messages in thread
From: Michael Kerrisk (man-pages) @ 2012-04-28  7:29 UTC (permalink / raw)
  To: Jason Baron
  Cc: mcgrathr-hpIqsD4AKlfQT0dZR+AlfA,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	avi-H+wXaHxf7aLQT0dZR+AlfA, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	qemu-devel-qX2TKyscuCcdnm+yROfE0A, Linux API

Hello Jason,

On Sat, Apr 28, 2012 at 6:43 AM, Jason Baron <jbaron-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, Apr 24, 2012 at 10:42:16AM +1200, Michael Kerrisk wrote:
>> Jason,
>>
>> On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron <jbaron-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> > Hi,
>> >
>> > The motivation for this change was that I was looking at a way for a qemu-kvm
>> > process, to exclude the guest memory from its core dump, which can be quite
>> > large. There are already a number of filter flags in
>> > /proc/<pid>/coredump_filter, however, these allow one to specify 'types' of
>> > kernel memory, not specific address ranges (which is needed in this case).
>> >
>> > Since there are no more vma flags available, the first patch eliminates the
>> > need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to
>> > mark vdso and vsyscall pages. However, it is simple enough to check if a vma
>> > covers a vdso or vsyscall page without the need for this flag.
>> >
>> > The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
>> > 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags:
>> > 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to
>> > work the same as before unless 'MADV_DONTDUMP' is set on the region.
>> >
>> > The qemu code which implements this features is at:
>> > http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
>> >
>> > In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch.
>> >
>> > I also believe that the 'MADV_DONTDUMP' flag might be useful for security
>> > sensitive apps, which might want to select which areas are dumped.
>>
>> Since we have
>> MADV_DODUMP
>> MADV_DONTDUMP
>> MADV_NODUMP
>> heading for userspace in 3.4, would you be willing to write patches
>> for the madvise(2) man page to describe these flags?
>>
>> See http://www.kernel.org/doc/man-pages/download.html for details on
>> accessing man-pages Git.
>>
>> Cheers,
>>
>> Michael
>>
>> PS Please also CC linux-api@ when making API/ABI changes.
>>
>
> Ok, here's a stab at manpage patch, let me know if I should send it as a
> separate patch. Thanks.
>
> -Jason
>
>
> diff --git a/man2/madvise.2 b/man2/madvise.2
> index 36f988a..472c23a 100644
> --- a/man2/madvise.2
> +++ b/man2/madvise.2
> @@ -247,6 +247,22 @@ Ensures that memory in the address range specified by
>  and
>  .IR length
>  will not be collapsed into huge pages.
> +.TP
> +.BR MADV_DONTDUMP " (since Linux 3.4)"
> +Explicitly exclude from a core dump those pages in the range specified by
> +.I addr
> +and
> +.IR length .
> +Applications may have large areas of memory which are known not to be useful in
> +diagnosing a core dump. This specification takes precedence over the bit mask that
> +is set via the
> +.I /proc/PID/coredump_filter
> +file (see
> +.BR core (5)).
> +.TP
> +.BR MADV_DODUMP " (since Linux 3.4)"
> +Undo the effect of an earlier
> +.BR MADV_DONTDUMP.
>  .SH "RETURN VALUE"
>  On success
>  .BR madvise ()
> @@ -356,4 +372,5 @@ from the system call, as it should).
>  .BR mmap (2),
>  .BR mprotect (2),
>  .BR msync (2),
> -.BR munmap (2)
> +.BR munmap (2),
> +.BR core (5)

Thanks! I tweaked this patch a little and applied the version below.

Cheers,

Michael

--- a/man2/madvise.2
+++ b/man2/madvise.2
@@ -247,6 +247,24 @@ Ensures that memory in the address range specified by
 and
 .IR length
 will not be collapsed into huge pages.
+.TP
+.BR MADV_DONTDUMP " (since Linux 3.4)"
+Exclude from a core dump those pages in the range specified by
+.I addr
+and
+.IR length .
+This is useful in applications that have large areas of memory
+that are known not to be useful in a core dump.
+The effect of
+.BR MADV_DONTDUMP
+takes precedence over the bit mask that is set via the
+.I /proc/PID/coredump_filter
+file (see
+.BR core (5)).
+.TP
+.BR MADV_DODUMP " (since Linux 3.4)"
+Undo the effect of an earlier
+.BR MADV_DONTDUMP .
 .SH "RETURN VALUE"
 On success
 .BR madvise ()
@@ -356,4 +374,5 @@ from the system call, as it should).
 .BR mmap (2),
 .BR mprotect (2),
 .BR msync (2),
-.BR munmap (2)
+.BR munmap (2),
+.BR core (5)

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2012-04-28  7:29 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-07 17:00 [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP Jason Baron
2012-03-07 17:00 ` [Qemu-devel] " Jason Baron
2012-03-07 17:00 ` [PATCH 1/2] core dump: drop VM_ALWAYSDUMP flag Jason Baron
2012-03-07 17:00   ` [Qemu-devel] " Jason Baron
2012-03-07 17:59   ` Roland McGrath
2012-03-07 17:59     ` [Qemu-devel] " Roland McGrath
2012-03-07 18:50     ` Jason Baron
2012-03-07 18:50       ` [Qemu-devel] " Jason Baron
2012-03-07 19:43       ` Roland McGrath
2012-03-07 19:43         ` [Qemu-devel] " Roland McGrath
2012-03-07 21:19         ` Jason Baron
2012-03-07 21:19           ` [Qemu-devel] " Jason Baron
2012-03-07 21:26           ` Chris Metcalf
2012-03-07 21:26             ` [Qemu-devel] " Chris Metcalf
2012-03-07 21:36             ` Jason Baron
2012-03-07 21:36               ` [Qemu-devel] " Jason Baron
2012-03-07 21:41           ` Roland McGrath
2012-03-07 21:41             ` [Qemu-devel] " Roland McGrath
2012-03-07 17:00 ` [PATCH 2/2] core dump: add a new VM_DONTDUMP flag Jason Baron
2012-03-07 17:00   ` [Qemu-devel] " Jason Baron
2012-03-07 22:30 ` [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP Andrew Morton
2012-03-07 22:30   ` [Qemu-devel] " Andrew Morton
2012-03-08  1:32   ` Jason Baron
2012-03-08  1:32     ` [Qemu-devel] " Jason Baron
2012-04-23 22:42 ` Michael Kerrisk
2012-04-23 22:42   ` Michael Kerrisk
2012-04-27 18:43   ` Jason Baron
2012-04-27 18:43     ` Jason Baron
2012-04-28  7:29     ` Michael Kerrisk (man-pages)
2012-04-28  7:29       ` Michael Kerrisk (man-pages)

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.