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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4E1764E7.7090804@intel.com>
Date:	Fri, 08 Jul 2011 13:13:27 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Russell King <rmk@....linux.org.uk>
CC:	Qin Dehua <qindehua@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"santosh.shilimkar@...com" <santosh.shilimkar@...com>,
	"neilb@...e.de" <neilb@...e.de>,
	"Jiang, Dave" <dave.jiang@...el.com>
Subject: Re: PROBLEM: ARM-dma-mapping-fix-for-speculative-prefetching cause
 OOPS

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/