linux-kernel - Re: 2nd attempt: help with dma_alloc_coherent() + dma_free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Jan 2013 09:24:22 -0700
From:	Jonathan Corbet <corbet@....net>
To:	Jeff Chua <jeff.chua.linux@...il.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: 2nd attempt: help with dma_alloc_coherent() +
 dma_free_coherent()

On Tue, 8 Jan 2013 23:51:59 +0800
Jeff Chua <jeff.chua.linux@...il.com> wrote:

> I'm trying to understand how this oops in the diva driver and it's just a
> simple dma_alloc_coherent() followed by dma_free_coherent(), but it oops.
> Why?

Hmm...from a quick look...

> static u32 *clock_data_addr;
> static dma_addr_t clock_data_bus_addr;
> 
>         if((clock_data_addr = dma_alloc_coherent(NULL, PAGE_SIZE,
>                         &clock_data_bus_addr, GFP_KERNEL)) != 0) {
>                 printk(KERN_INFO "dma_alloc_coherent ok\n");
>                 memset (clock_data_addr, 0x00, PAGE_SIZE);
>         } else
>                 printk(KERN_INFO "dma_alloc_coherent bad!!!\n");
>         if(clock_data_addr) {
>                 printk(KERN_INFO "dma_free_coherent!!!\n");
>                 dma_free_coherent(NULL, PAGE_SIZE, clock_data_addr,
>                         clock_data_bus_addr);
>                 clock_data_addr = NULL;
>         }

Perhaps passing NULL as your device structure pointer might just have
something to do with a crash due to a null pointer dereference?  If you're
doing DMA, you should have a device.  Try passing it and you might just
find that things work better.

(Incidentally, this:

> IP: [<ffffffff813ec01c>] iommu_no_mapping+0xc/0xee

is a fairly good clue as well - it's trying to dereference the device
structure pointer).

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/