linux-kernel - Re: [RFC PATCH 1/1] dmaengine: introduce dmaengine_bh

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <b309e54a-b3b6-49f9-af85-2df5ffbe13bf@app.fastmail.com>
Date: Tue, 13 Jan 2026 08:33:44 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: Allen <allen.lkml@...il.com>
Cc: "Vinod Koul" <vkoul@...nel.org>, "Kees Cook" <kees@...nel.org>,
 dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/1] dmaengine: introduce dmaengine_bh_wq and bh helpers

On Mon, Jan 12, 2026, at 23:20, Allen wrote:
>> >   A hardirq callback path feels like a larger API change, so I’d
>> > prefer to handle that as a separate follow‑up (e.g. explicit hardirq
>> >  callback/flag + user migration where safe). Thoughts?
>>
>> Yes, definitely keep that separate. I still think that this is
>> what we want eventually for a bigger improvement, but your
>> patch seems valuable on its own as well.
>>
>
> Thanks for the detailed feedback. I’ll respin along these lines:
>
>   - Split the series into two patches: (1) introduce the per‑channel BH API,
>     (2) switch the vchan implementation over to the WQ_BH backend if we decide
>     to keep that step. This should make the progression clearer.
>
>   - The dmaengine_*_bh_wq() helpers will be made static; only dma_chan_*_bh()
>     stays exported.

Sounds good, yes.

>   - I won’t try to move the other per‑driver tasklets onto the shared queue in
>     this series. That feels like a separate discussion, and the right context
>     (hardirq/threaded/workqueue) may vary by driver.

I'm not sure we are talking about the same thing here. I do think we should
try to have all the callbacks in each dmaengine driver go through the same
per-channel deferral mechanism. What I meant to say is that all the tasklets
that are not used for the client callbacks should be separate from those,
e.g. the pl330_dotask() handler is used for unexpected events unrelated
to a channel.

>   - I’ll keep the hardirq callback path separate. For that follow‑up, I can plan
>     to add an explicit “hardirq safe” request bit (e.g. a new dma_ctrl_flags)
>     and update vchan_cookie_complete() to invoke the callback directly when
>     requested; otherwise it stays on the tasklet path.
>
>   If you’d prefer I drop the WQ_BH conversion entirely for now and keep only the
>   tasklet‑based per‑channel API, I can do that too.

No, I think that part is fine.

     Arnd