linux-kernel - Re: Question: dmaengine: dma_request_chan_by

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] [day] [month] [year] [list]

Date:   Mon, 24 Apr 2023 22:16:05 +0300
From:   Péter Ujfalusi <peter.ujfalusi@...il.com>
To:     Vaishnav Achath <vaishnav.a@...com>, dmaengine@...r.kernel.org,
        linux-kernel@...r.kernel.org, vkoul@...nel.org
Cc:     Vignesh Raghavendra <vigneshr@...com>,
        "J, KEERTHY" <j-keerthy@...com>, u-kumar1@...com,
        Jayesh Choudhary <j-choudhary@...com>,
        "Menon, Nishanth" <nm@...com>
Subject: Re: Question: dmaengine: dma_request_chan_by_mask() and DMA
 controller probe order

Hi,

On 4/19/23 11:27, Vaishnav Achath wrote:
> Hi,
> 
> In dma_request_chan_by_mask() , the probe defer logic returns -EPROBE_DEFER if
> there are no DMA devices registered yet. But in case of multiple DMA controllers
> in an SoC and when only one(or a subset) of the controllers have finished probe
> dma_request_chan_by_mask() can return -ENODEV incorrectly since the first DMA
> device probed might not support the particular mask requested.

That change was added by
ec8ca8e3b4809 ("dmaengine: dma_request_chan_by_mask() to handle deferred
probing")
Which apparently only works if we have a single DMA controller or
multiple with similar capabilities.

> What is the recommended solution to avoid situation like these?

I would say, that in case of dma_request_chan_by_mask() it might be
reasonable to return -EPROBE_DEFER if the mask cannot be satisfied with
the probed DMA controllers.
With the dma_request_chan() we know which DMA we are waiting for while
with the give me any channel which can do this, we don't.

On the other hand we have users where they fallback to CPU memcpy or PIO
mode if a DMA channel is not available, returning -EPROBE_DEFER would
break them for sure.

Probably a notification system of some sort or deferred channel request
with a callback?

> Consider the following scenario for example:
> 
> SoC has two DMA controllers, one instance of system DMA, one dedicated for
> Camera subsytem which does not support DMA_MEMCPY and has lesser number of channels.
> 
> * Camera subsystem DMA is probed first.
> * Another peripheral requests dma_request_chan_by_mask(DMA_MEMCPY)
> * dmaengine returns -ENODEV for above as the controller with DMA_MEMCPY support
> is not ready yet.
> * System DMA is probed later but peripheral driver failed to start with DMA.

A while ago I have sent a series to add support for 'dma-domains':
https://lkml.kernel.org/lkml/20190906141816.24095-1-peter.ujfalusi@ti.com/

That would handle this use case fine. Looks like I did not had time to
update (or rewrite?) it based on the comments...

-- 
Péter