Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions

["Danilo Krummrich" <dakr@kernel.org>]

On Wed Feb 11, 2026 at 4:00 PM CET, Boris Brezillon wrote:
> On Wed, 11 Feb 2026 15:38:32 +0100
> "Danilo Krummrich" <dakr@kernel.org> wrote:
>
>> On Wed Feb 11, 2026 at 12:12 PM CET, Boris Brezillon wrote:
>> > On Wed, 11 Feb 2026 12:00:30 +0100
>> > "Danilo Krummrich" <dakr@kernel.org> wrote:  
>> >> I.e. sharing a workqueue between JobQs is fine, but we have to ensure they can't
>> >> be used for anything else.  
>> >
>> > Totally agree with that, and that's where I was going with this special
>> > DmaFenceWorkqueue wrapper/abstract, that would only accept
>> > scheduling MaySignalDmaFencesWorkItem objects.  
>> 
>> Not sure if it has to be that complicated (for a first shot). At least for the
>> JobQ it would probably be enough to have a helper to create a new, let's say,
>> struct JobQueueWorker that encapsulates a (reference counted) workqueue, but
>> does not give access to it outside of jobq.rs.
>
> Except we need to schedule some work items that are in the
> DMA-signaling path but not directly controlled by the jobq.rs
> implementation (see [1] for the post-execution work we schedule in
> panthor).
>
> The two options I can think of are:
>
> 1. Add a an unsafe interface to schedule work items on the wq attached
>    to JobQ. Safety requirements in that case being compliance with the
>    DMA-fence signalling rules.
> 2. The thing I was describing before, where we add the concept of
>    DmaFenceWorkqueue that can only take MaySignalDmaFencesWorkItem. We
>    can then have a DmaFenceWorkqueue that's global, and pass it to the
>    JobQueue so it can use it for its own work item.
>
> We could start with option 1, sure, but since we're going to need to
> schedule post-execution work items that have to be considered part of
> the DMA-signalling path, I'd rather have these concepts clearly defined
> from the start.
>
> Mind if I give this DmaFenceWorkqueue/MaySignalDmaFencesWorkItem a try
> to see what it looks like a get the discussion going from there
> (hopefully it's just a thin wrapper around a regular
> Workqueue/WorkItem, with an extra dma_fence_signalling annotation in
> the WorkItem::run() path), or are you completely against the idea?

Not at all, I think it's a good generalization.

But I'm very skeptical about the "we allow drivers to schedule arbitrary work on
the (shared) JobQueue workqueue" part. I think drivers can just have a separate
workqueue for such use-cases.

> [1]https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/gpu/drm/panthor/panthor_sched.c#L1913