public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Philippe De Muyter <phdm@macqel.be>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-kernel@vger.kernel.org,
	libdc1394-devel@lists.sourceforge.net,
	hidehiro.kawai.ez@hitachi.com,
	linux1394-devel@lists.sourceforge.net
Subject: Re: mmap'ed memory in core files ?
Date: Wed, 2 Jul 2008 15:16:52 +0200	[thread overview]
Message-ID: <20080702131652.GA12138@frolo.macqel> (raw)
In-Reply-To: <486B739B.8050807@s5r6.in-berlin.de>

On Wed, Jul 02, 2008 at 02:24:59PM +0200, Stefan Richter wrote:
>>> 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:
>>>>> 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.
>
> This shouldn't be a problem to you as far as I understand.  I suppose 
> "memory mapped I/O pages" means registers of PCI devices, mapped into the 
> memory address space.
>
> The DMA buffer which you would like to get included in the core file is 
> normal RAM (I suppose: allocated by the kernel in the kernel's virtual 
> address space, mapped into the application client's address space by 
> mmap(), and also mapped into the FireWire controller's local bus address 
> space for it to write received data into).

I agree with your analysis, but the sentence takes as exemple 'frame buffer'
which I don't think are registers. I have tested with a video1394 client,
and I do not get the mmapped video memory in the core file, even with
/proc/PID/coredump_filter set to 0xf.  So, while I agree it seems technically
feasible, it does not seem to be currently implemented :(

Philippe

  reply	other threads:[~2008-07-02 13:17 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 [this message]
2008-07-03  3:51       ` Hidehiro Kawai
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=20080702131652.GA12138@frolo.macqel \
    --to=phdm@macqel.be \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=libdc1394-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=mtk.manpages@gmail.com \
    --cc=mtk.manpages@googlemail.com \
    --cc=stefanr@s5r6.in-berlin.de \
    /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