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  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:   Wed, 25 May 2022 11:04:11 -0700
From:   Allen Pais <>
To:     Arnd Bergmann <>
Cc:     David Laight <>,
        Linus Walleij <>,
        Vincent Guittot <>,
        "" <>,
        Stefan Roese <>, Vinod Koul <>,
        Kees Cook <>,
        "" <>,
        Ludovic Desroches <>,
        Tudor Ambarus <>,
        Florian Fainelli <>,
        Ray Jui <>,
        Scott Branden <>,
        bcm-kernel-feedback-list <>,
        Nicolas Saenz Julienne <>,
        Paul Cercueil <>,
        "" <>,
        Gustavo Pimentel <>,
        Viresh Kumar <>,
        Andy Shevchenko <>,
        Leo Li <>,
        "" <>,
        Zhou Wang <>,
        Shawn Guo <>,
        Sascha Hauer <>,
        Sean Wang <>,
        Matthias Brugger <>,
        Andreas Färber <>,
        Manivannan Sadhasivam <>,
        Logan Gunthorpe <>,
        Sanjay R Mehta <>,
        Daniel Mack <>,
        Haojian Zhuang <>,
        Robert Jarzmik <>,
        Andy Gross <>,
        Bjorn Andersson <>,
        Krzysztof Kozlowski <>,
        "" <>,
        Orson Zhai <>,
        Baolin Wang <>,
        Lyra Zhang <>,
        Patrice CHOTARD <>,
        Chen-Yu Tsai <>,
        Jernej Škrabec <>,
        Samuel Holland <>,
        "" <>,
        Linux Kernel Mailing List <>
Subject: Re: [RFC 1/1] drivers/dma/*: replace tasklets with workqueue

>> Thank you Linus, Arnd, Vincent and David for the feedback.
>> This is a lot more than a just conversion of API’s. I am in the process
>> Of replacing tasklets with threaded irq’s and hopefully that should be
>> A better solution than using workqueues.
> I don't think that is much better for the case of the DMA engine
> callbacks than the work queue, the problem I pointed out here
> is scheduling into task context, which may be too expensive
> in some cases, but whether it is or not depends on the slave
> driver, not the dmaengine driver.

Fair point. Deferring all callbacks to task context is not the ideal
Way forward. I will work on the approach you shared,

>1. add helper functions to call the callback functions from a
>tasklet locally defined in drivers/dma/dmaengine.c to allow
>deferring it from hardirq context

>2. Change all tasklets that are not part of the callback
>mechanism to work queue functions, I only see
>xilinx_dpdma_chan_err_task in the patch, but there
>may be more

>3. change all drivers to move their custom tasklets back into
>hardirq context and instead call the new helper for deferring
>the callback.

>4. Extend the dmaengine callback API to let slave drivers
>pick hardirq, tasklet or task context for the callback.
>task context can mean either a workqueue, or a threaded
>IRQ here, with the default remaining the tasklet version.

>5. Change slave drivers to pick either hardirq or task context
>depending on their requirements

>6. Remove the tasklet version.


> Even if all the slave drivers are better off using task context
> (threaded irq or workqueue), you need to look at the slave
> drivers first before you can convert the dmaengine drivers.

Powered by blists - more mailing lists