[PATCH 0/2] Add explicit coredump filtering for DAX mappings

[PATCH 0/2] Add explicit coredump filtering for DAX mappings

[Ross Zwisler]

Add two new flags to the existing coredump mechanism for ELF files to allow
us to explicitly filter DAX mappings.  This is desirable because DAX
mappings, like hugetlb mappings, have the potential to be very large.

The coredump code relies on get_user_page() to populate the coredump file
with the appropriate data, and for DAX mappings this currently fails.  This
results in a hole being placed in the coredump file, so you end up reading
back zeros.  Once the get_user_pages() patch series from Dan Williams [1]
is merged, DAX core dumps will give real data.

I have a patch ready for core(5) to update the documentation on the new
filtering flags.  I'll send it out once this gets merged.

[1] http://thread.gmane.org/gmane.linux.kernel.mm/139026

Ross Zwisler (2):
  coredump: add DAX filtering for ELF coredumps
  coredump: add DAX filtering for FDPIC ELF coredumps

 Documentation/filesystems/proc.txt | 22 ++++++++++++----------
 fs/binfmt_elf.c                    | 10 ++++++++++
 fs/binfmt_elf_fdpic.c              | 15 +++++++++++++++
 include/linux/sched.h              |  4 +++-
 4 files changed, 40 insertions(+), 11 deletions(-)

-- 
2.1.0

[PATCH 1/2] coredump: add DAX filtering for ELF coredumps

[Ross Zwisler]

Add two new flags to the existing coredump mechanism for ELF files to
allow us to explicitly filter DAX mappings.  This is desirable because
DAX mappings, like hugetlb mappings, have the potential to be very
large.

Update the coredump_filter documentation in
Documentation/filesystems/proc.txt so that it addresses the new DAX
coredump flags.  Also update the documented default value of
coredump_filter to be consistent with the core(5) man page.  The
documentation being updated talks about bit 4, Dump ELF headers, which
is enabled if CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is turned on in the
kernel config.  This kernel config option defaults to "y" if both ELF
binaries and coredump are enabled.

Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
---
 Documentation/filesystems/proc.txt | 22 ++++++++++++----------
 fs/binfmt_elf.c                    | 10 ++++++++++
 include/linux/sched.h              |  4 +++-
 3 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index d411ca6..6f887cf 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1598,16 +1598,16 @@ Documentation/accounting.
 ---------------------------------------------------------------
 When a process is dumped, all anonymous memory is written to a core file as
 long as the size of the core file isn't limited. But sometimes we don't want
-to dump some memory segments, for example, huge shared memory. Conversely,
-sometimes we want to save file-backed memory segments into a core file, not
-only the individual files.
+to dump some memory segments, for example, huge shared memory or DAX.
+Conversely, sometimes we want to save file-backed memory segments into a core
+file, not only the individual files.
 
 /proc/<pid>/coredump_filter allows you to customize which memory segments
 will be dumped when the <pid> process is dumped. coredump_filter is a bitmask
 of memory types. If a bit of the bitmask is set, memory segments of the
 corresponding memory type are dumped, otherwise they are not dumped.
 
-The following 7 memory types are supported:
+The following 9 memory types are supported:
   - (bit 0) anonymous private memory
   - (bit 1) anonymous shared memory
   - (bit 2) file-backed private memory
@@ -1616,20 +1616,22 @@ The following 7 memory types are supported:
             effective only if the bit 2 is cleared)
   - (bit 5) hugetlb private memory
   - (bit 6) hugetlb shared memory
+  - (bit 7) DAX private memory
+  - (bit 8) DAX shared memory
 
   Note that MMIO pages such as frame buffer are never dumped and vDSO pages
   are always dumped regardless of the bitmask status.
 
-  Note bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only
-  effected by bit 5-6.
+  Note that bits 0-4 don't affect hugetlb or DAX memory. hugetlb memory is
+  only affected by bit 5-6, and DAX is only affected by bits 7-8.
 
-Default value of coredump_filter is 0x23; this means all anonymous memory
-segments and hugetlb private memory are dumped.
+The default value of coredump_filter is 0x33; this means all anonymous memory
+segments, ELF header pages and hugetlb private memory are dumped.
 
 If you don't want to dump all shared memory segments attached to pid 1234,
-write 0x21 to the process's proc file.
+write 0x31 to the process's proc file.
 
-  $ echo 0x21 > /proc/1234/coredump_filter
+  $ echo 0x31 > /proc/1234/coredump_filter
 
 When a new process is created, the process inherits the bitmask status from its
 parent. It is useful to set up coredump_filter before the program runs.
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 6b65996..5f399ea 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -35,6 +35,7 @@
 #include <linux/utsname.h>
 #include <linux/coredump.h>
 #include <linux/sched.h>
+#include <linux/dax.h>
 #include <asm/uaccess.h>
 #include <asm/param.h>
 #include <asm/page.h>
@@ -1236,6 +1237,15 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma,
 	if (vma->vm_flags & VM_DONTDUMP)
 		return 0;
 
+	/* support for DAX */
+	if (vma_is_dax(vma)) {
+		if ((vma->vm_flags & VM_SHARED) && FILTER(DAX_SHARED))
+			goto whole;
+		if (!(vma->vm_flags & VM_SHARED) && FILTER(DAX_PRIVATE))
+			goto whole;
+		return 0;
+	}
+
 	/* Hugetlb memory check */
 	if (vma->vm_flags & VM_HUGETLB) {
 		if ((vma->vm_flags & VM_SHARED) && FILTER(HUGETLB_SHARED))
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b7b9501..3c02d92 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -483,9 +483,11 @@ static inline int get_dumpable(struct mm_struct *mm)
 #define MMF_DUMP_ELF_HEADERS	6
 #define MMF_DUMP_HUGETLB_PRIVATE 7
 #define MMF_DUMP_HUGETLB_SHARED  8
+#define MMF_DUMP_DAX_PRIVATE	9
+#define MMF_DUMP_DAX_SHARED	10
 
 #define MMF_DUMP_FILTER_SHIFT	MMF_DUMPABLE_BITS
-#define MMF_DUMP_FILTER_BITS	7
+#define MMF_DUMP_FILTER_BITS	9
 #define MMF_DUMP_FILTER_MASK \
 	(((1 << MMF_DUMP_FILTER_BITS) - 1) << MMF_DUMP_FILTER_SHIFT)
 #define MMF_DUMP_FILTER_DEFAULT \
-- 
2.1.0

[PATCH 2/2] coredump: add DAX filtering for FDPIC ELF coredumps

[Ross Zwisler]

Add explicit filtering for DAX mappings to FDPIC ELF coredump.  This is
useful because DAX mappings have the potential to be very large.

This patch has only been compile tested.

Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
---
 fs/binfmt_elf_fdpic.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index d3634bf..8632501 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -35,6 +35,7 @@
 #include <linux/elf-fdpic.h>
 #include <linux/elfcore.h>
 #include <linux/coredump.h>
+#include <linux/dax.h>
 
 #include <asm/uaccess.h>
 #include <asm/param.h>
@@ -1206,6 +1207,20 @@ static int maydump(struct vm_area_struct *vma, unsigned long mm_flags)
 		return 0;
 	}
 
+	/* support for DAX */
+	if (vma_is_dax(vma)) {
+		if (vma->vm_flags & VM_SHARED) {
+			dump_ok = test_bit(MMF_DUMP_DAX_SHARED, &mm_flags);
+			kdcore("%08lx: %08lx: %s (DAX shared)", vma->vm_start,
+			       vma->vm_flags, dump_ok ? "yes" : "no");
+		} else {
+			dump_ok = test_bit(MMF_DUMP_DAX_PRIVATE, &mm_flags);
+			kdcore("%08lx: %08lx: %s (DAX private)", vma->vm_start,
+			       vma->vm_flags, dump_ok ? "yes" : "no");
+		}
+		return dump_ok;
+	}
+
 	/* By default, dump shared memory if mapped from an anonymous file. */
 	if (vma->vm_flags & VM_SHARED) {
 		if (file_inode(vma->vm_file)->i_nlink == 0) {
-- 
2.1.0

Re: [PATCH 0/2] Add explicit coredump filtering for DAX mappings

[Ross Zwisler]

On Mon, Oct 05, 2015 at 04:33:35PM -0600, Ross Zwisler wrote:
> Add two new flags to the existing coredump mechanism for ELF files to allow
> us to explicitly filter DAX mappings.  This is desirable because DAX
> mappings, like hugetlb mappings, have the potential to be very large.
> 
> The coredump code relies on get_user_page() to populate the coredump file
> with the appropriate data, and for DAX mappings this currently fails.  This
> results in a hole being placed in the coredump file, so you end up reading
> back zeros.  Once the get_user_pages() patch series from Dan Williams [1]
> is merged, DAX core dumps will give real data.
> 
> I have a patch ready for core(5) to update the documentation on the new
> filtering flags.  I'll send it out once this gets merged.
> 
> [1] http://thread.gmane.org/gmane.linux.kernel.mm/139026
> 
> Ross Zwisler (2):
>   coredump: add DAX filtering for ELF coredumps
>   coredump: add DAX filtering for FDPIC ELF coredumps
> 
>  Documentation/filesystems/proc.txt | 22 ++++++++++++----------
>  fs/binfmt_elf.c                    | 10 ++++++++++
>  fs/binfmt_elf_fdpic.c              | 15 +++++++++++++++
>  include/linux/sched.h              |  4 +++-
>  4 files changed, 40 insertions(+), 11 deletions(-)
> 
> -- 
> 2.1.0

Ping?

Re: [PATCH 0/2] Add explicit coredump filtering for DAX mappings

[Jeff Moyer]

Ross Zwisler <ross.zwisler@linux.intel.com> writes:

> Add two new flags to the existing coredump mechanism for ELF files to allow
> us to explicitly filter DAX mappings.  This is desirable because DAX
> mappings, like hugetlb mappings, have the potential to be very large.
>
> The coredump code relies on get_user_page() to populate the coredump file
> with the appropriate data, and for DAX mappings this currently fails.  This
> results in a hole being placed in the coredump file, so you end up reading
> back zeros.  Once the get_user_pages() patch series from Dan Williams [1]
> is merged, DAX core dumps will give real data.
>
> I have a patch ready for core(5) to update the documentation on the new
> filtering flags.  I'll send it out once this gets merged.

Looks straight-forward.

Acked-by: Jeff Moyer <jmoyer@redhat.com>