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. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
