linux-kernel - Re: BUG at drivers/iommu/amd

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:   Mon, 21 Nov 2016 16:47:59 -0500
From:   Mark Hounschell <markh@...pro.net>
To:     Joerg Roedel <joro@...tes.org>
Cc:     iommu@...ts.linux-foundation.org,
        Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: BUG at drivers/iommu/amd_iommu.c:1436!

On 11/21/2016 10:32 AM, Joerg Roedel wrote:
> On Fri, Nov 18, 2016 at 09:04:05AM -0500, Mark Hounschell wrote:
>> OK. It's attached.
> 
>> [   45.033715] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1158 check_unmap+0x4ef/0x990
>> [   45.037651] 3c59x 0000:04:04.0: DMA-API: device driver failed to check map error[device address=0x00000000ffedf840] [size=1536 bytes] [mapped as single]
> 
> Okay, there is a dma-debug warning from the 3c59x driver. Can you please
> blacklist this driver (or compile it out) and re-try? The dma-debug code
> will only show the first warning and stop then. So any possible warnings
> from your out-of-tree driver will not be shown as long as the 3c59x
> driver is loaded.
> 
> Alternativly you can write 1 to dma-api/all_errors in debug-fs so that
> it will show all errors. But I suggest to unload the 3com driver first
> and then load your driver.
> 

OK, I did get this message before the reported BUG message.

gpiohsd gpiohsd: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0xffffffffffee8000] [size=8192 bytes]

But I've verified that the dma_addr_t that I get for the alloc, and also use for the free is 0x00000000ffee8000 in this case? Is device "address=0xffffffffffee8000" in that message a bug in the message or do we have a sign extended address problem? It seems strange to me, I've never seen a dma_addr_t given, when using the iommu, that high. In the past I've seen them as usually 0x00xxxxxx?

I have also verified that simply changing from pci_alloc/free_consistent to the newer DMA API fixes my issue and I get no such messages.

Mark