linux-kernel - RE: pcm|dmaengine|imx-sdma race condition on i.MX6

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: <a64ae27d9f1348ecae6adc74969cc88c@skidata.com>
Date:   Mon, 17 Aug 2020 11:38:10 +0000
From:   Benjamin Bara - SKIDATA <Benjamin.Bara@...data.com>
To:     Robin Gong <yibin.gong@....com>
CC:     "timur@...nel.org" <timur@...nel.org>,
        "nicoleotsuka@...il.com" <nicoleotsuka@...il.com>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        dl-linux-imx <linux-imx@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        Richard Leitner - SKIDATA <Richard.Leitner@...data.com>
Subject: RE: pcm|dmaengine|imx-sdma race condition on i.MX6

> -----Original Message-----
> From: Robin Gong <yibin.gong@....com>
> Sent: Montag, 17. August 2020 11:23
> busy_wait is not good I think, would you please have a try with the attached patch
> which is based on https://lkml.org/lkml/2020/8/11/111? The basic idea is
> to keep the freed descriptor into another list for freeing in later terminate_worker
> instead of freeing directly all in terminate_worker by vchan_get_all_descriptors
> which may break next descriptor coming soon

The idea sounds good, but with this attempt we are still not sure that the 1ms
(the ultimate reason why this is a problem) is awaited between DMA disabling and
re-enabling.

If we are allowed to leave the atomic PCM context on each trigger, synchronize the DMA and then
enter it back again, everything is fine.
This might be the most performant and elegant solution.
However, since we are in an atomic context for a reason, it might not be wanted by the PCM system
that the DMA termination completion of the previous context happens within the next call,
but we are not sure about that.
In this case, a busy wait is not a good solution, but a necessary one,
or at least the only valid solution we are aware of.

Anyhow, based on my understanding, either the start or the stop trigger has to wait the 1ms
(or whats left of it).