Re: BUG: NULL pointer dereference at 00000000 -- IP: [<f8e783d5>] :b43:b43_dma_mapping_error+0x16/0x155

[Vegard Nossum]

On Tue, Jun 10, 2008 at 4:37 PM, Michael Buesch <mb@xxxxxxxxx> wrote:
> On Tuesday 10 June 2008 16:34:21 Michael Buesch wrote:
>> On Tuesday 10 June 2008 16:29:17 Vegard Nossum wrote:
>> > On Tue, Jun 10, 2008 at 4:23 PM, Michael Buesch <mb@xxxxxxxxx> wrote:
>> > > On Tuesday 10 June 2008 16:09:37 Miles Lane wrote:
>> > >> BUG: unable to handle kernel NULL pointer dereference at 00000000
>> > >> IP: [<f8e783d5>] :b43:b43_dma_mapping_error+0x16/0x155
>> > >
>> > >
>> > > It seems to crash at
>> > >  60 extern const struct dma_mapping_ops *dma_ops;
>> > >  61
>> > >  62 static inline int dma_mapping_error(dma_addr_t dma_addr)
>> > >  63 {
>> > >  64         if (dma_ops->mapping_error)
>> > >  65                 return dma_ops->mapping_error(dma_addr);
>> > >  66
>> > >  67         return (dma_addr == bad_dma_address);
>> > >  68 }
>> >
>> > No, this is wrong.
>> >
>> > /* Check if a DMA mapping address is invalid. */
>> > static bool b43_dma_mapping_error(struct b43_dmaring *ring,
>> >                                   dma_addr_t addr,
>> >                                   size_t buffersize, bool dma_to_device)
>> > {
>> >         if (unlikely(dma_mapping_error(ring->dev->dev->dma_dev, addr)))
>> >
>> > It crashes on this line ---^
>>
>> Which calls dma_mapping_error(), correct?
>>

Yes. Sorry, I should have explained. It happened before the call to
dma_mapping_error(), so it has to be during the argument processing.
addr2line -i ftw ;-) (shows inlines)

$ addr2line -e drivers/net/wireless/b43/b43.o -i 24cf9
drivers/net/wireless/b43/dma.c:521

>> But you are right. I see the bug now.
>> ring->dev is assigned after the call.
>> I wonder why it works reliably on all of my machines.
>>
>
> Ehm no wait a second...
> What strange tree are you looking at?
> This is a copy of the code from my local tree.
>
>  516 /* Check if a DMA mapping address is invalid. */
>  517 static bool b43_dma_mapping_error(struct b43_dmaring *ring,
>  518                                   dma_addr_t addr,
>  519                                   size_t buffersize, bool dma_to_device)
>  520 {
>  521         if (unlikely(dma_mapping_error(addr)))
>  522                 return 1;
>
> This code is perfectly fine.
> This must be some merge error in some upstream tree.

I am looking at v2.6.26-rc5-mm2.

This change comes from

commit 353c409463ecba63c3a41a992d3f5fba935eada9
Author: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
Date:   Fri May 23 19:02:30 2008 +0000

    dma-mapping-add-the-device-argument-to-dma_mapping_error

    Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
    architecture does:

    This enables us to cleanly fix the Calgary IOMMU issue that some devices
    are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).

    I think that per-device dma_mapping_ops support would be also helpful for
    KVM people to support PCI passthrough but Andi thinks that this makes it
    difficult to support the PCI passthrough (see the above thread).  So I
    CC'ed this to KVM camp.  Comments are appreciated.

    A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
    pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
    NULL, the system-wide dma_ops pointer is used as before.

    If it's useful for KVM people, I plan to implement a mechanism to register
    a hook called when a new pci (or dma capable) device is created (it works
    with hot plugging).  It enables IOMMUs to set up an appropriate
    dma_mapping_ops per device.

    The major obstacle is that dma_mapping_error doesn't take a pointer to the
    device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
    device.  Note all the POWER IOMMUs use the same dma_mapping_error function
    so this is not a problem for POWER but x86 IOMMUs use different
    dma_mapping_error functions.

    The first patch adds the device argument to dma_mapping_error.  The patch
    is trivial but large since it touches lots of drivers and dma-mapping.h in
    all the architecture.

(Added to Cc.)


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/