public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Philippe De Muyter <phdm@macqel.be>
To: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>,
	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, 3 Jul 2008 11:22:47 +0200	[thread overview]
Message-ID: <20080703092247.GA13430@frolo.macqel> (raw)
In-Reply-To: <486C4CC5.2060006@hitachi.com>

Hello Hidehiro,

On Thu, Jul 03, 2008 at 12:51:33PM +0900, Hidehiro Kawai wrote:
> 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,

Thanks for your patch, but it will not help here. Before applying it blindly
I asked myself if the mmapped region was tagged VM_IO, because it is actually
a simple ram zone, not an I/O zone, and the answer is it is not a VM_IO zone.
Details :

drivers/ieee1394/video1394.c:
    static int video1394_mmap(struct file *file, struct vm_area_struct *vma)
    {
    [...]
    return dma_region_mmap(&ctx->current_ctx->dma, file, vma);
    }

drivers/ieee1394/dma.c:
    int dma_region_mmap(struct dma_region *dma, struct file *file,
			struct vm_area_struct *vma)
    {
    [...]
    vma->vm_ops = &dma_region_vm_ops;
    vma->vm_private_data = dma;
    vma->vm_file = file;
    vma->vm_flags |= VM_RESERVED;

    return 0;
    }

So, actually the zone I would like to get dumped in the core file is tagged
VM_RESERVED.

I see the following ways to solve my problem :
    - do not tag the zone as VM_RESERVED in ieee1394::dma_region_mmap
    - tag the zone as VM_ALWAYSDUMP in ieee1394::dma_region_mmap
    - add a bit in coredump_filter to dump the VM_RESERVED zones.

As I don't know the real meaning of VM_RESERVED, I do not know which choice
is the best one for the official kernel tree, but locally I'll go for
adding VM_ALWAYSDUMP in ieee1394::dma_region_mmap.

Philippe

  reply	other threads:[~2008-07-03 12:29 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
2008-07-03  9:22         ` Philippe De Muyter [this message]
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=20080703092247.GA13430@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=mtk.manpages@gmail.com \
    --cc=mtk.manpages@googlemail.com \
    --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