lkml.org 
[lkml]   [2008]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: mmap'ed memory in core files ?
    Hello,

    Philippe De Muyter wrote:

    > 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.

    I'm afraid I don't know real usages of VM_RESERVED and VM_IO, either.
    Allowing everyone to choose whether dump the dma region or not,
    perhaps we need to introduce a new VM flag (e.g. VM_DUMPABLE) and
    a coredump_filter bit which controls (VM_IO | VM_RESERVED) &&
    VM_DUMPABLE area, for example.

    I think it is also OK to just add VM_ALWAYSDUMP flag to the dma
    region if the device driver knows the region is safely readable
    and small enough.

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



    \
     
     \ /
      Last update: 2008-07-04 07:53    [W:3.237 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site