linux-kernel - Re: [PATCH 5/9] dmaengine: dw-edma: HDMA: Fix possible race condition in remote setup

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: <20230620153549.0677da97@kmaincent-XPS-13-7390>
Date:   Tue, 20 Jun 2023 15:35:49 +0200
From:   Köry Maincent <kory.maincent@...tlin.com>
To:     Serge Semin <fancer.lancer@...il.com>
Cc:     Cai Huoqing <cai.huoqing@...ux.dev>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Vinod Koul <vkoul@...nel.org>,
        Gustavo Pimentel <Gustavo.Pimentel@...opsys.com>,
        dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Herve Codina <herve.codina@...tlin.com>
Subject: Re: [PATCH 5/9] dmaengine: dw-edma: HDMA: Fix possible race
 condition in remote setup

On Tue, 20 Jun 2023 15:07:37 +0300
Serge Semin <fancer.lancer@...il.com> wrote:

> > This one is only hypothetical. It appears to me that writing the control
> > after the configuration of sar and dar is more relevant to prevent race
> > issues and should be the usual coding choice. Also you are right saying
> > that it will be relevant only for the LL tree entries recycling.
> > Simple question from non DMA expert: isn't cyclic DMA mode recycle the LL
> > tree entries?   
> 
> Ideally the driver should have been designed in the way you say:
> define a ring of the Linked List entries and recycle the already used
> entries while the already enabled entries are being handled by the
> DMA-engine (a similar approach is described in the DW PCIe/eDMA hw
> manual). DW eDMA engine CSRs and LLI descriptor provide enough
> functionality for that. Alas the driver implementation is more
> straightforward:
> 1. Each DMA-engine config: SG-list, cyclic, interleaved is split up
> into the "burst" entries. SG-list entries are directly mapped to the
> eDMA "burst" entries. Cyclic iterations are unrolled into the
> respective number of eDMA "burst" entries. A similar story with the
> interleaved transactions.
> 2. If there is no enough entries in the Linked-List memory to fully
> execute the requested DMA-transfers, then another so called DW eDMA
> "chunk" is allocated.
> 3. DW eDMA engine executes the "chunks" one after another stopping at
> the end of each one and recharging the engine with the next "chunk" until
> the last one is finished.
> 
> It isn't the most effective architecture, but that's how it was
> originally developed by Gustavo. Anyway discussing it is a good food
> for thoughts for the driver refactoring though.)

thanks for enlightening me, then indeed we will never face the issue solved by
this patches as we won't recycle LL tree entries.