linux-kernel - Re: [PATCH v2] dmaengine: edma: Implement device

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: <56BC6C94.1060409@ti.com>
Date:	Thu, 11 Feb 2016 13:12:20 +0200
From:	Peter Ujfalusi <peter.ujfalusi@...com>
To:	Lars-Peter Clausen <lars@...afoo.de>, <vinod.koul@...el.com>
CC:	<linux-kernel@...r.kernel.org>, <dmaengine@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <nsekhar@...com>,
	<linux-omap@...r.kernel.org>
Subject: Re: [PATCH v2] dmaengine: edma: Implement device_synchronize callback

On 02/11/2016 11:41 AM, Lars-Peter Clausen wrote:
> On 02/11/2016 10:08 AM, Peter Ujfalusi wrote:
>> We need the callback to support the dmaengine_terminate_sync().
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@...com>
> 
> Looks good, but I noticed a slight race condition in
> edma_completion_handler(). You need to fetch echan->desc while holding the
> vchan.lock. Otherwise this can race against terminate_all() and the callback
> might get scheduled even though terminate_all() completed and then there is
> a race where the synchronize() operation could be called before the callback
> gets scheduled, which means it doesn't do its intended job. Highly unlikely
> to happen, but theoretically possible.

Right, actually I had (have) another series fixing the very same race in a
different way - patching the terminate_all (series attached).
We have seen race with RT kernel on uniprocessor setup.

The tasklet_kill after the terminate_all will execute the scheduled task
unconditionally, so the vchan_complete() will run after we have terminated the
channel, which might be not what we want.
I have also seen a race condition as explained in the first patch. The only
way I was able to fix that by using the attached patches. Unfortunately I can
not test RT with mainline yet, so I'm not 100% sure if by using the
dmaengine_terminate_sync() in drivers will fix the issue.

-- 
Péter

View attachment "0001-dmaengine-virt-dma-Support-for-ignoring-callback-aft.patch" of type "text/x-patch" (4081 bytes)

View attachment "0002-dmaengine-omap-dma-Prevent-race-between-vchan_comple.patch" of type "text/x-patch" (1215 bytes)

View attachment "0003-dmaengine-edma-Prevent-race-between-vchan_complete-a.patch" of type "text/x-patch" (1231 bytes)