linux-kernel - Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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] [day] [month] [year] [list]

Message-ID: <55143D59.40005@compro.net>
Date:	Thu, 26 Mar 2015 13:09:45 -0400
From:	Mark Hounschell <markh@...pro.net>
To:	Joerg Roedel <joro@...tes.org>
CC:	iommu@...ts.linux-foundation.org, Hannes Reinecke <hare@...e.de>,
	"linux-scsi@...r.kernel.org >> SCSI development list" 
	<linux-scsi@...r.kernel.org>, linux-kernel@...r.kernel.org
Subject: Re: BUG: SCSI aic7xxx driver and AMD IOMMU

On 03/26/2015 11:52 AM, Joerg Roedel wrote:
> Hi Mark,
>
> On Thu, Mar 26, 2015 at 10:58:15AM -0400, Mark Hounschell wrote:
>> Sorry but CMA was still badly broken. I have a patch below that works.
>
> In which way is it broken? What happens when you try to allocate memory
> with dma_alloc_coherent?
>

I got Oops on both the alloc and free and I had to hit the reset button.

>> I've tested it with small (no CMA) and large (with CMA) dma's using
>> dma_alloc_coherent. The patch below is just the "git diff" from your
>> cloned tree piped to a file then copied into this email. If you require
>> an official patch I can send one. Just let me know.
>
> The main differences I can spot are that you change the order (first
> CMA, then buddy) and you manually align the input size. I can see the
> reason for the later, but why does CMA need to be tried first?
>

I believe that is how dma_alloc_coherent works. If  CMA is present it 
uses it. Even for small allocations. If not present then it does the 
best it can. That patch was derived by looking at the Intel iommu driver 
works properly. Maybe you should take a look at that.

>> Also, in my opinion, this CMA thing is clearly a BUG not a feature
>> request. The AMD iommu clearly breaks CMA. I feel what ever fix
>> you are happy with should be back ported to stable.
>
> It is not a BUG, the interface definition for dma_alloc_coherent does
> not specify that it can allocate infinite amounts of memory. So this
> patch does not qualify for stable.
>
>

I don't care what the "the interface definition for dma_alloc_coherent" 
says. If it does not describe it's use with CMA, it is outdated. Maybe 
the "interface definition for dma_alloc_coherent" was done before CMA 
was implemented.

Maybe you should be looking at CMA Documentation.  Unfortunately there 
does not yet seem to be any in the Documentation dir. Probably because 
CMA is supposed to be transparent to the DMA API. You know, one should 
not need to details about it, etc...

It is a BUG. To access CMA you use dma_alloc_coherent. You have 
completely highjacked that function.  You have broken CMA. PERIOD. That 
is a BUG.

Regards
Mark
--
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/