lkml.org 
[lkml]   [2009]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
    On Tue, Jul 14, 2009 at 01:12:24PM -0700, David Miller wrote:
    > From: Joerg Roedel <joerg.roedel@amd.com>
    > Date: Tue, 14 Jul 2009 11:23:55 +0200
    >
    > > On Tue, Jul 14, 2009 at 10:40:16AM +0900, FUJITA Tomonori wrote:
    > >> On Mon, 13 Jul 2009 20:56:21 -0400
    > >> Robert Reif <reif@earthlink.net> wrote:
    > >>
    > >> > The bad address is within the kernel so it looks like
    > >> > it's catching a real bug.
    > >> >
    > >> > cat kallsyms | grep f0007000
    > >> > f0007000 T trapbase_cpu3
    > >> >
    > >> > WARNING: at lib/dma-debug.c:873 check_for_illegal_area+0xc8/0x100()
    > >> > esp ffd7ba30: DMA-API: device driver maps memory from kernel text or
    > >> > rodata [addr=f0007000] [len=4096]
    > >> > Modules linked in: ext3 jbd sd_mod sun_esp esp_scsi scsi_transport_spi
    > >>
    > >> Ok, I looked at check_for_illegal_area() in dma-debug.
    > >>
    > >> What check_for_illegal_area() does looks bogus to me with some of I/O
    > >> remapping hardware.
    > >
    > > Can you be more specific about this one? check_for_illegal_area() should
    > > not depend on any hardware because all it does is checking the machine
    > > addresses to be mapped.
    >
    > The check can't work properly on sparc32.
    >
    > Sparc32 always maps the kernel to a fixed physical location, and it
    > therefore can execute in the identity mapping area of physical memory
    > like where all the free pages and kmalloc areas live virtually.
    >
    > So if we free up some pages within the kernel image (because the
    > memory is unused, for exmple that's what's happening here with the
    > extra trap table pages on Robert's machine) we have pages in the free
    > page pool that are located right inside of the kernel text, data, etc.
    >
    > We'll thus need a way to turn off these checks somehow. You could
    > also augment this check by seeing if there is a backing page, and if
    > so, whether it is PageReserved or not. That's just one idea.

    Hmm these checks sound specific and hard to maintain. I think its best
    to give architectures the option whether to enable this check or not.

    Joerg




    \
     
     \ /
      Last update: 2009-07-21 18:09    [W:0.031 / U:62.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site