Re: PROBLEM: ARM-dma-mapping-fix-for-speculative-prefetching cause OOPS

[Dan Williams <dan.j.williams@intel.com>]

On 7/8/2011 10:32 AM, Russell King wrote:
> On Fri, Jul 08, 2011 at 09:07:51AM +0100, Russell King wrote:
>> On Fri, Jul 08, 2011 at 12:38:38PM +0800, Qin Dehua wrote:
>>> After doing the above changes, the kernel just report  BUG_ON(dir ==
>>> DMA_BIDIRECTIONAL):
>>
>> That's really unfortunate.
>>
>> The only other thing I can think which may help is to enable all the
>> raid5, async_tx and dmaengine debug code.  And I hope you have
>> DMA_API_DEBUG enabled in your .config ?
>
> I'm really grasping at straws here...
>
> I'll add to this that I'm out of ideas at the moment (I don't know the
> RAID5 nor the async offload code), and the only way I can think of
> resolving this is to revert the commit.
>
> While that sounds like a good thing to do, it means people using ARMv6
> and later CPUs will be risking data corruption, which I don't think is
> that desirable either - and will in itself cause a regression there.

Not much of a choice but crashing is better than data corruption. 
Disabling CONFIG_ASYNC_TX_DMA until the mapping violations can be 
resolved is probably the better course of action.  Something like.

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 1c28816..cb254a1 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -247,6 +247,7 @@ config NET_DMA
  config ASYNC_TX_DMA
         bool "Async_tx: Offload support for the async_tx api"
         depends on DMA_ENGINE
+       depends on !ARM
         help
           This allows the async_tx api to take advantage of offload 
engines for
           memcpy, memset, xor, and raid6 p+q operations.  If your 
platform has


>
> So we really need to the bottom of what's going on (which I suspect
> may be due to DMA API abuse by the async offload stuff - mapping the
> same buffer multiple times with differing attributes.)  Why that would
> impact sh->count I've no idea.
>

This is concerning, I'll see about dusting off my iop34x and 
reproducing.  Might not be for a week or so...

--
Dan