linux-kernel - Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

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]

Date:	Mon, 08 Aug 2016 08:10:51 -0400
From:	okaya@...eaurora.org
To:	Vinod Koul <vinod.koul@...el.com>
Cc:	dmaengine@...r.kernel.org, timur@...eaurora.org,
	Christopher Covington <cov@...eaurora.org>,
	linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	dmaengine-owner@...r.kernel.org
Subject: Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the
 callback

On 2016-08-08 04:51, Vinod Koul wrote:
> 
>> This patch is needed to fix a race condition as the commit message 
>> describes.
>> The callback is called before returning the descriptor back to free 
>> pool.
>> 
>> If the client calls free resources, the descriptor that was not 
>> returned to free pool gets lost due
>> to race condition.
> 
> Hmmm, if you have txn's pending and client wants to free up, shouldn't
> the pending txn's be cleaned up? Sound like a different bug to me..
> 
> So if I submit 5 txn's and now want to freeup, will you still leak
> descriptors? Doesn't sound as right behaviour to me.
> 

If free is called from the callback, current code will leak the current 
descriptor where free was called. It will release the other 4.

Because of ordering problem, descriptor is not in the active, pending or 
free pool.

I check pending txn by looking at active and queued lists when free is 
called.

After the callback, I put the descriptor back to free pool. At this 
moment, it is already too late.


>> I'll refactor the code after Dave's change for passing the error code 
>> while calling the
>> callback. That will be a different patch anyhow.
> 
> Yes the error reporting is different