linux-kernel - Re: Revert "dmaengine: pl330: add DMA

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: <b232b906-9359-bea1-447f-2c1341cc19d5@metafoo.de>
Date:   Thu, 17 May 2018 19:22:26 +0200
From:   Lars-Peter Clausen <lars@...afoo.de>
To:     Frank Mori Hess <fmh6jj@...il.com>,
        Vinod Koul <vinod.koul@...aro.org>
Cc:     Marek Szyprowski <m.szyprowski@...sung.com>,
        dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
        Dan Williams <dan.j.williams@...el.com>,
        r.baldyga@...kerion.com, Krzysztof Kozlowski <krzk@...nel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Linux Samsung SOC <linux-samsung-soc@...r.kernel.org>
Subject: Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On 05/17/2018 06:20 PM, Frank Mori Hess wrote:
> Sorry to keep coming back to this, but I'm experiencing a bit of
> incredulity that you are saying what you seem to be saying.  You seem
> to be saying dmaengine provides no way to permanently stop a transfer
> safely other than transferring the full number of bytes initially
> requested.  So the proper resolution is the 8250 serial driver needs
> to remove rx dma support, because they are just trying to do something
> that is not supported.

The problem is not so much on the software side but even more so on the
hardware side. Not all hardware even supports aborting a transfer with no
data loss because there is no precise measurement of how much data has been
transferred. The residue that is reported is always the lower bound, this
much has been transferred but it might actually have been more.

And even if hardware supports precise residue reporting there often is no
synchronization mechanism to ensure that there is no pending data anywhere
in the pipeline. This doesn't even have to be inside the DMA's buffers, the
DMA might have send the data to the peripheral but it has not arrived at the
peripheral side.

If the peripheral has a memory mapped FIFO there will typically be some
confirmation that the data was received, but with a dedicated DMA bus
between the DMA controller and the peripheral that is often not the case.
And for the first case the DMA controller also needs to actually expose the
information how many acknowledgements it has received.

Because there are basically two different resides, residue one is how much
data has been read from/written to memory and the other is how much data has
been read from/written to the peripheral. Any differences between the two
will account for in flight data.

What I'd recommend is to add a flush_sync() operation to the DMA interface.
This function would wait until all in flight data transfers have been
completed. That makes it safe to call terminate() without the risk of
loosing data and also allow accurate residue reporting.

Although I'd expect that there is fair risk that implementations will not
get flush_sync() 100% correct because it requires in-depth knowledge about
the internal behavior of the DMA which is often not documented.