On Mon, 09 Feb 2026 09:19:46 +0100 Philipp Stanner <[email protected]> wrote:
> On Fri, 2026-02-06 at 11:23 +0100, Danilo Krummrich wrote: > > On Thu Feb 5, 2026 at 9:57 AM CET, Boris Brezillon wrote: > > > On Tue, 3 Feb 2026 09:14:01 +0100 > > > Philipp Stanner <[email protected]> wrote: > > > Unfortunately, I don't know how to translate that in rust, but we > > > need a way to check if any path code path does a DmaFence.signal(), > > > go back to the entry point (for a WorkItem, that would be > > > WorkItem::run() for instance), and make it a DmaFenceSignallingPath. > > > Not only that, but we need to know all the deps that make it so > > > this path can be called (if I take the WorkItem example, that would > > > be the path that leads to the WorkItem being scheduled). > > > > I think we need a guard object for this that is not Send, just like for any > > other lock. > > > > Internally, those markers rely on lockdep, i.e. they just acquire and > > release a > > "fake" lock. > > The guard object would be created through fence.begin_signalling(), wouldn't > it? It shouldn't be a (&self)-method, because at the start of a DMA signaling path, you don't necessarily know which fence you're going to signal (you might actually signal several of them). > And when it drops you call dma_fence_end_signalling()? Yep, dma_fence_end_signalling() should be called when the guard is dropped. > > How would that ensure that the driver actually marks the signalling region > correctly? Nothing, and that's a problem we have in C: you have no way of telling which code section is going to be a DMA-signaling path. I can't think of any way to make that safer in rust, unfortunately. The best I can think of would be to - Have a special DmaFenceSignalWorkItem (wrapper a WorkItem with extra constraints) that's designed for DMA-fence signaling, and that takes the DmaSignaling guard around the ::run() call. - We would then need to ensure that any code path scheduling this work item is also in a DMA-signaling path by taking a ref to the DmaSignalingGuard. This of course doesn't guarantee that the section is wide enough to prevent any non-authorized operations in any path leading to this WorkItem scheduling, but it would at least force the caller to consider the problem.
