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, 27 Apr 2022 08:58:52 -0700
From:   Allen Pais <>
To:     Dave Jiang <>
Cc:     Vinod Koul <>,,, Kees Cook <>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Subject: Re: [RFC 1/1] drivers/dma/*: replace tasklets with workqueue

>> On 19-04-22, 21:16, Allen Pais wrote:
>>> The tasklet is an old API which will be deprecated, workqueue API
>>> cab be used instead of them.
>> What is the reason for tasklet removal, I am not sure old is a reason to
>> remove an API...
>>> This patch replaces the tasklet usage in drivers/dma/* with a
>>> simple work.
>> Dmaengines need very high throughput, one of the reasons in dmaengine
>> API design to use tasklet was higher priority given to them. Will the
>> workqueue allow that...?
> Wouldn't the logical move be to convert threaded irq IF tasklets are being deprecated rather than using workqueue as replacement?

  Logically yes. Would all tasklets need to be moved to threaded irq, that I am not sure. I think
Workqueues does the job.

> Also, wouldn't all the spin_lock_bh() calls need to be changed to spin_lock_irqsave() now? Probably not as simple as just replace tasklet with workqueue.

Yes, this was carefully looked at as we have moved from the interrupt/softirq context to process context.


Powered by blists - more mailing lists