From: Hante Meuleman <meuleman@broadcom.com> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Will Deacon <will.deacon@arm.com>, Arend Van Spriel <arend@broadcom.com>, Marek Szyprowski <m.szyprowski@samsung.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, David Miller <davem@davemloft.net>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, brcm80211-dev-list <brcm80211-dev-list@broadcom.com>, linux-wireless <linux-wireless@vger.kernel.org> Subject: RE: using DMA-API on ARM Date: Fri, 5 Dec 2014 14:20:30 +0000 [thread overview] Message-ID: <F51492713EF10846800D8C0ED37A7DCE01901765@SJEXCHMB15.corp.ad.broadcom.com> (raw) In-Reply-To: <20141205132332.GS11285@n2100.arm.linux.org.uk> Ok, I'll add the necessary debug to get all the information out, but it will take some time to get it done, so I won't have anything before Monday. -----Original Message----- From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk] Sent: vrijdag 5 december 2014 14:24 To: Hante Meuleman Cc: Will Deacon; Arend Van Spriel; Marek Szyprowski; linux-arm-kernel@lists.infradead.org; David Miller; linux-kernel@vger.kernel.org; brcm80211-dev-list; linux-wireless Subject: Re: using DMA-API on ARM Please wrap your message - replying to a message which looks like this in my editor is far from easy, and gives me much more work to /manually/ reformat it before I can reply to it: On Fri, Dec 05, 2014 at 12:56:45PM +0000, Hante Meuleman wrote: > The problem is with data coming from device, so DMA from device to host. The $ > > However: this indicates that dma_alloc_coherent on an ARM target may result i$ > > Regards, > Hante Thanks. On Fri, Dec 05, 2014 at 12:56:45PM +0000, Hante Meuleman wrote: > However: this indicates that dma_alloc_coherent on an ARM target may > result in a memory buffer which can be cached which conflicts with > the API of this function. If the memory has an alias which is cacheable, it is possible for cache lines to get allocated via that alias, even if the alias has no explicit accesses to it. This is something which I've been going on for quite literally /years/ - mismatched cache attributes can cause unpredictable behaviour. I've had a lot of push back from people who are of the opinion that "if it works for me, then there isn't a problem" and I eventually gave up fighting the battle, especially as the ARM architecture people weakened my reasoning behind it by publishing a relaxation of the "no differing attributes" issue. This was particularly true of those who wanted to use ioremap() on system memory - and cases such as dma_init_coherent_memory(). So, I never fixed this problem in the original DMA allocator code; I basically gave up with it. It's a latent bug which did need to be fixed, and is still present today in the non-CMA case. The symptoms which you are reporting sound very much like this kind of problem - the virtual address for the memory returned by dma_alloc_coherent() will not be cacheable memory - it will have been remapped using map_vm_area(). However, there could very well be a fully cacheable lowmem mapping of that memory, which if a read (speculative or otherwise) will bring a cache line in, and because the caches are VIPT or PIPT, that cache line can be hit via the non-cacheable mapping too. What I /really/ need is more evidence of this to tell those disbelievers where to stick their flawed arguments. :) -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
WARNING: multiple messages have this Message-ID (diff)
From: meuleman@broadcom.com (Hante Meuleman) To: linux-arm-kernel@lists.infradead.org Subject: using DMA-API on ARM Date: Fri, 5 Dec 2014 14:20:30 +0000 [thread overview] Message-ID: <F51492713EF10846800D8C0ED37A7DCE01901765@SJEXCHMB15.corp.ad.broadcom.com> (raw) In-Reply-To: <20141205132332.GS11285@n2100.arm.linux.org.uk> Ok, I'll add the necessary debug to get all the information out, but it will take some time to get it done, so I won't have anything before Monday. -----Original Message----- From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] Sent: vrijdag 5 december 2014 14:24 To: Hante Meuleman Cc: Will Deacon; Arend Van Spriel; Marek Szyprowski; linux-arm-kernel at lists.infradead.org; David Miller; linux-kernel at vger.kernel.org; brcm80211-dev-list; linux-wireless Subject: Re: using DMA-API on ARM Please wrap your message - replying to a message which looks like this in my editor is far from easy, and gives me much more work to /manually/ reformat it before I can reply to it: On Fri, Dec 05, 2014 at 12:56:45PM +0000, Hante Meuleman wrote: > The problem is with data coming from device, so DMA from device to host. The $ > > However: this indicates that dma_alloc_coherent on an ARM target may result i$ > > Regards, > Hante Thanks. On Fri, Dec 05, 2014 at 12:56:45PM +0000, Hante Meuleman wrote: > However: this indicates that dma_alloc_coherent on an ARM target may > result in a memory buffer which can be cached which conflicts with > the API of this function. If the memory has an alias which is cacheable, it is possible for cache lines to get allocated via that alias, even if the alias has no explicit accesses to it. This is something which I've been going on for quite literally /years/ - mismatched cache attributes can cause unpredictable behaviour. I've had a lot of push back from people who are of the opinion that "if it works for me, then there isn't a problem" and I eventually gave up fighting the battle, especially as the ARM architecture people weakened my reasoning behind it by publishing a relaxation of the "no differing attributes" issue. This was particularly true of those who wanted to use ioremap() on system memory - and cases such as dma_init_coherent_memory(). So, I never fixed this problem in the original DMA allocator code; I basically gave up with it. It's a latent bug which did need to be fixed, and is still present today in the non-CMA case. The symptoms which you are reporting sound very much like this kind of problem - the virtual address for the memory returned by dma_alloc_coherent() will not be cacheable memory - it will have been remapped using map_vm_area(). However, there could very well be a fully cacheable lowmem mapping of that memory, which if a read (speculative or otherwise) will bring a cache line in, and because the caches are VIPT or PIPT, that cache line can be hit via the non-cacheable mapping too. What I /really/ need is more evidence of this to tell those disbelievers where to stick their flawed arguments. :) -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
next prev parent reply other threads:[~2014-12-05 14:20 UTC|newest] Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-12-05 9:22 using DMA-API on ARM Arend van Spriel 2014-12-05 9:22 ` Arend van Spriel 2014-12-05 9:22 ` Arend van Spriel 2014-12-05 9:45 ` Russell King - ARM Linux 2014-12-05 9:45 ` Russell King - ARM Linux 2014-12-05 9:45 ` Russell King - ARM Linux 2014-12-05 12:24 ` Will Deacon 2014-12-05 12:24 ` Will Deacon 2014-12-05 12:24 ` Will Deacon 2014-12-05 12:56 ` Hante Meuleman 2014-12-05 12:56 ` Hante Meuleman 2014-12-05 12:56 ` Hante Meuleman 2014-12-05 13:23 ` Russell King - ARM Linux 2014-12-05 13:23 ` Russell King - ARM Linux 2014-12-05 13:23 ` Russell King - ARM Linux 2014-12-05 14:20 ` Hante Meuleman [this message] 2014-12-05 14:20 ` Hante Meuleman 2014-12-05 14:20 ` Hante Meuleman 2014-12-05 14:47 ` Arend van Spriel 2014-12-05 14:47 ` Arend van Spriel 2014-12-05 14:47 ` Arend van Spriel 2014-12-08 13:47 ` Hante Meuleman 2014-12-08 13:47 ` Hante Meuleman 2014-12-08 13:47 ` Hante Meuleman 2014-12-08 15:01 ` Arnd Bergmann 2014-12-08 15:01 ` Arnd Bergmann 2014-12-08 15:17 ` Russell King - ARM Linux 2014-12-08 15:17 ` Russell King - ARM Linux 2014-12-08 15:22 ` Arnd Bergmann 2014-12-08 15:22 ` Arnd Bergmann 2014-12-08 16:03 ` Catalin Marinas 2014-12-08 16:03 ` Catalin Marinas 2014-12-08 16:03 ` Catalin Marinas 2014-12-08 17:01 ` Arend van Spriel 2014-12-08 17:01 ` Arend van Spriel 2014-12-08 17:01 ` Arend van Spriel 2014-12-09 10:19 ` Arend van Spriel 2014-12-09 10:19 ` Arend van Spriel 2014-12-09 10:19 ` Arend van Spriel 2014-12-09 10:29 ` Russell King - ARM Linux 2014-12-09 10:29 ` Russell King - ARM Linux 2014-12-09 10:29 ` Russell King - ARM Linux 2014-12-09 11:07 ` Arend van Spriel 2014-12-09 11:07 ` Arend van Spriel 2014-12-09 11:07 ` Arend van Spriel 2014-12-09 11:54 ` Catalin Marinas 2014-12-09 11:54 ` Catalin Marinas 2014-12-09 11:54 ` Catalin Marinas 2015-01-20 15:22 ` Fabio Estevam 2015-01-20 15:22 ` Fabio Estevam 2015-01-20 15:22 ` Fabio Estevam 2014-12-08 16:22 ` Arend van Spriel 2014-12-08 16:22 ` Arend van Spriel 2014-12-08 16:38 ` Arnd Bergmann 2014-12-08 16:38 ` Arnd Bergmann 2014-12-08 16:47 ` Russell King - ARM Linux 2014-12-08 16:47 ` Russell King - ARM Linux 2014-12-08 16:50 ` Catalin Marinas 2014-12-08 16:50 ` Catalin Marinas 2014-12-08 16:50 ` Catalin Marinas 2014-12-08 16:54 ` Russell King - ARM Linux 2014-12-08 16:54 ` Russell King - ARM Linux 2014-12-08 16:54 ` Russell King - ARM Linux 2014-12-05 15:06 ` Russell King - ARM Linux 2014-12-05 15:06 ` Russell King - ARM Linux 2014-12-05 15:06 ` Russell King - ARM Linux 2014-12-05 18:28 ` Catalin Marinas 2014-12-05 18:28 ` Catalin Marinas 2014-12-05 18:28 ` Catalin Marinas 2014-12-05 19:22 ` Arend van Spriel 2014-12-05 19:22 ` Arend van Spriel 2014-12-05 19:22 ` Arend van Spriel 2014-12-05 19:25 ` Russell King - ARM Linux 2014-12-05 19:25 ` Russell King - ARM Linux 2014-12-05 19:25 ` Russell King - ARM Linux 2014-12-05 12:43 ` Arend van Spriel 2014-12-05 12:43 ` Arend van Spriel 2014-12-05 12:43 ` Arend van Spriel 2014-12-05 12:59 ` Russell King - ARM Linux 2014-12-05 12:59 ` Russell King - ARM Linux 2014-12-05 12:59 ` Russell King - ARM Linux 2014-12-05 9:52 ` Arnd Bergmann 2014-12-05 9:52 ` Arnd Bergmann 2014-12-05 11:11 ` Russell King - ARM Linux 2014-12-05 11:11 ` Russell King - ARM Linux 2014-12-05 11:49 ` Hante Meuleman 2014-12-05 11:49 ` Hante Meuleman 2014-12-05 11:49 ` Hante Meuleman 2014-12-05 17:38 ` Catalin Marinas 2014-12-05 17:38 ` Catalin Marinas 2014-12-05 17:38 ` Catalin Marinas 2014-12-05 18:24 ` Russell King - ARM Linux 2014-12-05 18:24 ` Russell King - ARM Linux 2014-12-05 18:24 ` Russell King - ARM Linux 2014-12-05 18:31 ` Catalin Marinas 2014-12-05 18:31 ` Catalin Marinas 2014-12-05 18:31 ` Catalin Marinas 2014-12-05 18:39 ` Catalin Marinas 2014-12-05 18:39 ` Catalin Marinas 2014-12-05 18:39 ` Catalin Marinas 2014-12-05 18:53 ` Catalin Marinas 2014-12-05 18:53 ` Catalin Marinas 2014-12-05 18:53 ` Catalin Marinas 2014-12-05 19:50 ` Arend van Spriel 2014-12-05 19:50 ` Arend van Spriel 2014-12-05 19:50 ` Arend van Spriel 2014-12-08 12:55 ` Johannes Stezenbach 2014-12-08 12:55 ` Johannes Stezenbach 2014-12-08 12:55 ` Johannes Stezenbach 2014-12-08 15:55 ` Catalin Marinas 2014-12-08 15:55 ` Catalin Marinas 2014-12-08 15:55 ` Catalin Marinas 2014-12-08 16:50 ` Johannes Stezenbach 2014-12-08 16:50 ` Johannes Stezenbach 2014-12-08 16:50 ` Johannes Stezenbach
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=F51492713EF10846800D8C0ED37A7DCE01901765@SJEXCHMB15.corp.ad.broadcom.com \ --to=meuleman@broadcom.com \ --cc=arend@broadcom.com \ --cc=brcm80211-dev-list@broadcom.com \ --cc=davem@davemloft.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=m.szyprowski@samsung.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.