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: <6b5799a567d14cfb9ce34d278a33017d@skidata.com>
Date:   Wed, 19 Aug 2020 14:25:43 +0000
From:   Benjamin Bara - SKIDATA <Benjamin.Bara@...data.com>
To:     Lars-Peter Clausen <lars@...afoo.de>,
        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: Lars-Peter Clausen <lars@...afoo.de>
> Sent: Mittwoch, 19. August 2020 13:08
> I think this might be an sdma specific problem after all.
> dmaengine_terminate_async() will issue a request to stop the DMA. But it
> is still safe to issue the next transfer, even without calling
> dmaengine_synchronize(). The DMA should start the new transfer at its
> earliest convenience in that case.
> 
> dmaegine_synchronize() is so that the consumer has a guarantee that the
> DMA is finished using the resources (e.g. the memory buffers) associated
> with the DMA transfer so it can safely free them.

Thank you for the clarifications!

> I don't know how feasible this is to implement in the SDMA dmaengine
> driver. But I think what is should do is to have some flag to indicate
> if a terminate is in progress. If a new transfer is issued while
> terminate is in progress the transfer should go on a list. Once
> terminate finishes it should check the list and start the transfer if
> there are any on the list.

IMHO that's nearly what Robin's patches does, so this should be sufficient:
Putting the descriptors to free in an extra termination list and ensuring
that a new transfer is handled after the last termination is done.


@Robin:
Is it possible to tag the commits for the stable-tree
Cc: stable@...r.kernel.org?

Best regards and thank you all!
Benjamin
Richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ