linux-hardening - Re: [RFC 1/1] drivers/dma/*: replace tasklets with workqueue

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 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 <apais@...ux.microsoft.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     David Laight <David.Laight@...lab.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        "olivier.dautricourt@...lia.com" <olivier.dautricourt@...lia.com>,
        Stefan Roese <sr@...x.de>, Vinod Koul <vkoul@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
        Ludovic Desroches <ludovic.desroches@...rochip.com>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        Nicolas Saenz Julienne <nsaenz@...nel.org>,
        Paul Cercueil <paul@...pouillou.net>,
        "Eugeniy.Paltsev@...opsys.com" <Eugeniy.Paltsev@...opsys.com>,
        Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
        Viresh Kumar <vireshk@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Leo Li <leoyang.li@....com>,
        "zw@...kernel.org" <zw@...kernel.org>,
        Zhou Wang <wangzhou1@...ilicon.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Sean Wang <sean.wang@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Andreas Färber <afaerber@...e.de>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Logan Gunthorpe <logang@...tatee.com>,
        Sanjay R Mehta <sanju.mehta@....com>,
        Daniel Mack <daniel@...que.org>,
        Haojian Zhuang <haojian.zhuang@...il.com>,
        Robert Jarzmik <robert.jarzmik@...e.fr>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        "green.wan@...ive.com" <green.wan@...ive.com>,
        Orson Zhai <orsonzhai@...il.com>,
        Baolin Wang <baolin.wang7@...il.com>,
        Lyra Zhang <zhang.lyra@...il.com>,
        Patrice CHOTARD <patrice.chotard@...s.st.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Škrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
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.

Thanks.

> 
> 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.
>