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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLW5wg7Jcyw70+PChrY26Ydfy++K3oq_6ZoxSjqM_CKqsw@mail.gmail.com>
Date:	Wed, 20 Jul 2016 22:22:02 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	zhangfei <zhangfei.gao@...aro.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Jingoo Han <jg1.han@...sung.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Vinod Koul <vinod.koul@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Mark Brown <broonie@...nel.org>, Andy Green <andy@...mcat.com>
Subject: Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper
 dma api

On Wed, Jul 20, 2016 at 9:26 PM, zhangfei <zhangfei.gao@...aro.org> wrote:
>
>
> On 07/21/2016 11:53 AM, John Stultz wrote:
>>
>> After lots of debugging on an occasional DMA ERR issue, I realized
>> that the desc structures which we point the dma hardware are being
>> allocated out of regular memory. This means when we fill the desc
>> structures, that data doesn't always get flushed out to memory by
>> the time we start the dma transfer, resulting in the dma engine getting
>> some null values, resulting in a DMA ERR on the first irq.
>
>
> How about using wmb() flush before start dma to sync desc?

So I'm not going to pretend to be an expert here, but my understanding
is that wmb() syncrhonizes cpu write ordering operations across cpus,
so the cpus see all the changes before the wmb() before they see any
changes after.  But I'm not sure what effect wmb() has across cpu
cache to device ordering.   I don't think it works as a cache flush to
memory.

Andy's patch introducing the cyclic support actually had a wmb() in it
that I removed as I couldn't understand clearly why it was there (and
there wasn't a comment explaining, as required by checkpatch :).   But
even with that wmb(), the DMA ERR was still seen.

Only with these two new changes have I gotten to the point where I
can't seem to trigger the DMA error.

thanks
-john

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ