From: Mark Hounschell <markh@compro.net>
Subject: Re: BUG at drivers/iommu/amd_iommu.c:1436!
Reply-To: markh@compro.net
References: <838275de-6cac-93d8-ca04-54b06a24b3d4@compro.net>
 <20161117214141.GC2078@8bytes.org>
 <f4ababc2-64bf-fd0e-1d18-cb5963d23eb1@compro.net>
 <20161117220045.GD2078@8bytes.org>
 <b8260bfd-55c9-c029-1af1-e1ccc719dd3a@compro.net>
 <20161121153250.GE2078@8bytes.org>
 <4f6afa52-9634-79f4-01af-1ae047aa83f7@compro.net>
 <20161122084522.GF2078@8bytes.org>
To: Joerg Roedel <joro@8bytes.org>
Cc: iommu@lists.linux-foundation.org,
        Linux-kernel <linux-kernel@vger.kernel.org>
Organization: Compro Computer Svcs.
Message-ID: <6dc89f9c-bb32-d7e5-f72e-104e0a9afd48@compro.net>
Date: Tue, 22 Nov 2016 14:53:25 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161122084522.GF2078@8bytes.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1724
Lines: 39

On 11/22/2016 03:45 AM, Joerg Roedel wrote:
> On Mon, Nov 21, 2016 at 04:47:59PM -0500, Mark Hounschell wrote:
>> 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.
>
> Yes, this looks like a sign-extension bug somewhere. But its not in the
> amd-iommu driver, because dma-debug also sees it. And from what I can
> tell the dma-api interface seems to be fine. It consistently uses
> dma_addr_t to pass these values around.
>
> Where can I find the source of the failing code? I need exactly the code
> version that triggers the problem.
>
>

I certainly don't have a problem sending you the code but I'm sure you 
have better things to do than scour over some out of kernel GPL driver 
code. I see many many users of pci_alloc/free in kernel so it can't be 
broken as badly as it appears to me here. I'm going to just go ahead and 
convert this section of code to use the newer DMA API and be done with it.

It appears pci_alloc/free_consistent is going to be removed completely 
soon anyway.

Thanks
Mark