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:	Wed, 10 Aug 2016 22:53:10 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Lars-Peter Clausen <lars@...afoo.de>
Cc:	Russell King - ARM Linux <linux@...linux.org.uk>,
	Sinan Kaya <okaya@...eaurora.org>,
	linux-arm-msm@...r.kernel.org, timur@...eaurora.org,
	linux-kernel@...r.kernel.org,
	Christopher Covington <cov@...eaurora.org>,
	dmaengine@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the
 callback

On Mon, Aug 08, 2016 at 02:25:28PM +0200, Lars-Peter Clausen wrote:
> On 08/08/2016 11:08 AM, Vinod Koul wrote:
> > On Thu, Aug 04, 2016 at 05:59:30PM +0200, Lars-Peter Clausen wrote:
> >> On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote:
> >> [...]
> >>> What you instead need to do is to find some way to record in your
> >>> driver that transaction 2 failed, and when dma_cookie_status() says
> >>> that a transaction has DMA_COMPLETE status, you need to look up to
> >>> see whether it failed.
> >>
> >> In my opinion this is where the current API is broken by design. For each
> >> transfer that fails you need to store the cookie associated with that
> >> transfer in some kind of lookup table. Since there is no lifetime associated
> >> with a cookie entries in this table would need to be retained forever and it
> >> will grow unbound.
> > 
> > And how many drivers can report errors? And how many drivers can guarantee
> > DMA_COMPLETE implies transaction was succesful.
> 
> The former just a handful, the later hopefully all.
> 
> > 
> >> Ideally we'd mark error reporting through this interface as deprecated and
> >> discourage new users of the interface. As far as I can see most of the few
> >> drivers that do return DMA_ERROR get it wrong anyway, e.g. return it
> >> unconditionally for all cookies when an error occurred for any of them.
> > 
> > Error reporting is quite tricky as detection is a problem. So yes if you
> > can do so, it is highly encouraged to report using new interface which is
> > better than client checking after callback.
> > 
> > Btw what is the behaviour after error? I would think that client will see an
> > error and report to upper layer while initiaite closure of transaction. So
> > does driver need to keep the state for a longer time :-)
> 
> The problem is that this is not really clearly defined.
> 
> 1) What should be done when multiple descriptors are queued and an error is
> encountered on one of them. Should the descriptors that are after the one in
> the queue that caused the error be discarded or should they be executed as
> normal?

That is client's call.

But a reasonable way would be for client to propagate those errors up, so it
can terminate.

> 2) How long does a error result need to be retained. Can it be discarded
> when the terminate_all() is called, or can it be discarded when the next
> issue_pending() is called or should it be retained forever?

Uptill next terminate_all()

> Unless we can clearly define the semantics of error reporting it is very
> difficult for drivers to use it. Which is probably one of the reasons why
> there are only very few DMAengine consumers that do actual error checking.

Yes agreed, but most reasonable behaviour is to terminate. Also I would
expect the error reporting to be done thru new API and explcitly told that
we found error (if we can).

-  
~Vinod