Re: PROBLEM: ARM-dma-mapping-fix-for-speculative-prefetching causeOOPS

[Dan Williams]

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