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
| ||
|
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. >
Powered by blists - more mailing lists