From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752619AbbCZRJz (ORCPT ); Thu, 26 Mar 2015 13:09:55 -0400 Received: from smtp81.ord1c.emailsrvr.com ([108.166.43.81]:38333 "EHLO smtp81.ord1c.emailsrvr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752563AbbCZRJu (ORCPT ); Thu, 26 Mar 2015 13:09:50 -0400 X-SMTPDoctor-Processed: csmtpprox beta X-Sender-Id: markh@compro.net Message-ID: <55143D59.40005@compro.net> Date: Thu, 26 Mar 2015 13:09:45 -0400 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Joerg Roedel CC: iommu@lists.linux-foundation.org, Hannes Reinecke , "linux-scsi@vger.kernel.org >> SCSI development list" , linux-kernel@vger.kernel.org Subject: Re: BUG: SCSI aic7xxx driver and AMD IOMMU References: <54E1FFFA.1060403@compro.net> <54F60D33.8090401@compro.net> <20150323150304.GQ4441@8bytes.org> <5511513D.6090106@compro.net> <20150325135937.GR4441@8bytes.org> <20150325151332.GT4441@8bytes.org> <5512E412.9040807@compro.net> <20150326124559.GV4441@8bytes.org> <55141E87.8040506@compro.net> <20150326155248.GW4441@8bytes.org> In-Reply-To: <20150326155248.GW4441@8bytes.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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