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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAOMdWSLVk136RzEyiN76zqk65VLwYms0hCDi5Kww9FQppie12A@mail.gmail.com>
Date: Tue, 13 Jan 2026 11:31:35 -0800
From: Allen <allen.lkml@...il.com>
To: Arnd Bergmann <arnd@...db.de>
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

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

Hi Arnd,

Thanks for clarifying, I understand now. Yes, the intent will be to have
all per‑channel client callbacks go through the shared per‑channel deferral
mechanism (dma_chan_*_bh), while keeping any non‑callback tasklets/work
separate (e.g. pl330_dotask() for unexpected events).

I’ll keep WQ_BH and the per‑channel API as the common callback path, and in
follow‑on patches I’ll start converting driver callback paths to use it.

Thanks,
Allen


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



-- 
       - Allen