public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: Philippe De Muyter <phdm@macqel.be>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-kernel@vger.kernel.org,
	libdc1394-devel@lists.sourceforge.net, stefanr@s5r6.in-berlin.de,
	sugita <yumiko.sugita.yf@hitachi.com>,
	Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>
Subject: Re: mmap'ed memory in core files ?
Date: Thu, 03 Jul 2008 12:51:33 +0900	[thread overview]
Message-ID: <486C4CC5.2060006@hitachi.com> (raw)
In-Reply-To: <cfd18e0f0807020358k317575c6ra0187428098f0160@mail.gmail.com>

Hi,

Michael Kerrisk wrote:

> [CC+= hidehiro.kawai.ez@hitachi.com]
> 
> On Wed, Jul 2, 2008 at 12:50 PM, Philippe De Muyter <phdm@macqel.be> wrote:
> 
>>Hi Michael,
>>
>>On Tue, Jul 01, 2008 at 08:16:11PM +0200, Michael Kerrisk wrote:
>>
>>>On 7/1/08, Philippe De Muyter <phdm@macqel.be> wrote:
>>>
>>>>Hello everybody,
>>>>
>>>> I develop video acquisition software using the video1394 interface.
>>>> The images grabbed by the camera and iee1394 bus are kept in kernel
>>>> memory and made available to the user program through a mmap call done
>>>> in the libdc1394 library :
>>>>
>>>> dma_ring_buffer= mmap(0, vmmap.nb_buffers * vmmap.buf_size,
>>>>                PROT_READ|PROT_WRITE,MAP_SHARED, craw->capture.dma_fd, 0);
>>>>
>>>> Sometimes, my program crashes and produces a core file :)  It seems to
>>>> me that the core file does not contain the mmap'ed memory and hence
>>>> I cannot replay my program with the same image for debugging purpose.
>>>>
>>>> Is it possible to configure the kernel through /proc, or through the mmap
>>>> system call to have that mmapped segment in the core file, or do I need
>>>> to modify the kernel itself to obtain the behaviour I want ?  If I
>>>> need to modify the kernel, can some kind soul provide me some pointers ?
>>>
>>>
>>>Have a look at the section "Controlling which mappings are written to
>>>the core dump" in a recent core.5 man page:
>>>http://www.kernel.org/doc/man-pages/online/pages/man5/core.5.html
>>
>>thanks for the info.  I didn't know about /proc/PID/coredump_filter.
>>
>>that part was promising :
>>
>>      bit 2  Dump file-backed private mappings.
>>      bit 3  Dump file-backed shared mappings.
>>
>>   The default value of coredump_filter is 0x3; this reflects traditional
>>   Linux behavior and means that only anonymous memory segments are dumped.
>>
>>Unfortunately, the part that applies to me (I have tested it) is the next one :
>>
>>   Memory-mapped I/O pages such as frame buffer are never dumped, [...],
>>   regardless of the coredump_filter value.
>>
>>Is that a design decision, or a mere finding of the way it is implemented
>>now ?

MMIO pages have been not dumped since a long time ago, and I didn't target
them for the coredump_filter feature because I thought it was generally
danger to read MMIO pages.  As for frame buffer we would be able to
safely access to it, but there is no way to tell it from other MMIO
mappings, AFAIK.

>>So, back to my original question :
>>
>>Can some kind soul provide me some pointers to the way I should modify
>>the kernel to make the inclusion of the video1394 mmapped segment in
>>core files possible ?
> 
> 
> Perhaps Hidehiro, who wrote the coredump_filter feature, can provide insight.

The following patch may help.  To dump MMIO pages, set bit 5 of
coredump_filter.

$ echo 0x23 > /proc/<PID>/coredump_filter


Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
---
This patch is not intended to be merged to the upstream kernel
because the safeness of reading VM_IO mappings has not been
proved.

Index: linux-2.6.26-rc5-mm3/fs/binfmt_elf.c
===================================================================
--- linux-2.6.26-rc5-mm3.orig/fs/binfmt_elf.c
+++ linux-2.6.26-rc5-mm3/fs/binfmt_elf.c
@@ -1141,11 +1141,18 @@ static unsigned long vma_dump_size(struc
 	if (vma->vm_flags & VM_ALWAYSDUMP)
 		goto whole;
 
-	/* Do not dump I/O mapped devices or special mappings */
-	if (vma->vm_flags & (VM_IO | VM_RESERVED))
+#define FILTER(type)	(mm_flags & (1UL << MMF_DUMP_##type))
+
+	/* By default, do not dump memory mapped I/O mappings */
+	if (vma->vm_flags & VM_IO) {
+		if (FILTER(MMIO))
+			goto whole;
 		return 0;
+	}
 
-#define FILTER(type)	(mm_flags & (1UL << MMF_DUMP_##type))
+	/* Do not dump special mappings */
+	if (vma->vm_flags & VM_RESERVED)
+		return 0;
 
 	/* By default, dump shared memory if mapped from an anonymous file. */
 	if (vma->vm_flags & VM_SHARED) {
Index: linux-2.6.26-rc5-mm3/include/linux/sched.h
===================================================================
--- linux-2.6.26-rc5-mm3.orig/include/linux/sched.h
+++ linux-2.6.26-rc5-mm3/include/linux/sched.h
@@ -403,8 +403,9 @@ extern int get_dumpable(struct mm_struct
 #define MMF_DUMP_MAPPED_PRIVATE	4
 #define MMF_DUMP_MAPPED_SHARED	5
 #define MMF_DUMP_ELF_HEADERS	6
+#define MMF_DUMP_MMIO		7
 #define MMF_DUMP_FILTER_SHIFT	MMF_DUMPABLE_BITS
-#define MMF_DUMP_FILTER_BITS	5
+#define MMF_DUMP_FILTER_BITS	6
 #define MMF_DUMP_FILTER_MASK \
 	(((1 << MMF_DUMP_FILTER_BITS) - 1) << MMF_DUMP_FILTER_SHIFT)
 #define MMF_DUMP_FILTER_DEFAULT \



Regards,
-- 
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center


  parent reply	other threads:[~2008-07-03  7:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-01 13:21 mmap'ed memory in core files ? Philippe De Muyter
2008-07-01 18:16 ` Michael Kerrisk
2008-07-01 21:44   ` Bron Gondwana
2008-07-02  5:14     ` Michael Kerrisk
2008-07-02  6:35       ` Rob Mueller
2008-07-02 11:07         ` Andi Kleen
2008-07-02 11:52           ` Bron Gondwana
2008-07-02 10:50   ` Philippe De Muyter
2008-07-02 10:58     ` Michael Kerrisk
2008-07-02 11:04       ` Philippe De Muyter
2008-07-02 12:24         ` Stefan Richter
2008-07-02 13:16           ` Philippe De Muyter
2008-07-03  3:51       ` Hidehiro Kawai [this message]
2008-07-03  9:22         ` Philippe De Muyter
2008-07-04  5:50           ` Hidehiro Kawai
2008-07-04  6:33             ` Stefan Richter
2008-07-04 11:25               ` Philippe De Muyter
2008-07-04 14:29               ` Hugh Dickins
2008-07-04 11:13             ` Philippe De Muyter
2008-07-03  9:37         ` Philippe De Muyter
2008-07-03 16:52           ` [PATCH] ieee1394 : dump mmapped video1394 buffers in core files Philippe De Muyter
2008-07-04 18:33             ` Stefan Richter
2008-07-04 20:49               ` Philippe De Muyter
2008-07-02 13:30     ` mmap'ed memory in core files ? Christoph Hellwig
2008-07-02 11:01   ` Philippe De Muyter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=486C4CC5.2060006@hitachi.com \
    --to=hidehiro.kawai.ez@hitachi.com \
    --cc=libdc1394-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=mtk.manpages@googlemail.com \
    --cc=phdm@macqel.be \
    --cc=satoshi.oshima.fk@hitachi.com \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=yumiko.sugita.yf@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox