On Mon, Nov 03, 2025 at 12:43:32PM +0100, Christian König wrote: > On 10/31/25 18:44, Matthew Brost wrote: > >>> Not to derail the conversation, but I noticed that dma-fence-arrays can, > >>> in fact, signal out of order. The issue lies in dma-fence-cb, which > >>> signals the fence using irq_queue_work. Internally, irq_queue_work uses > >>> llist, a LIFO structure. So, if two dma-fence-arrays have all their > >>> fences signaled from a thread, the IRQ work that signals each individual > >>> dma-fence-array will execute out of order. > >>> > >>> We should probably fix this. > >> > >> No we don't. That's what I'm trying to point out all the time. > >> > >> The original idea of sharing the lock was to guarantee that fence signal > >> in order, but that never worked correct even for driver fences. > >> > >> The background is the optimization we do in the signaling fast path. E.g. > >> when dma_fence_is_signaled() is called. > >> > > > > Ah, yes—I see this now. I was operating under the assumption that fences > > on a timeline must signal in order, but that’s not actually true. What > > is true is that if a fence later on a timeline signals, all prior fences > > are complete (i.e., the underlying hardware condition is met, even if > > the software hasn’t signaled them yet). > > > > Could we document this somewhere in the dma-fence kernel docs? I can > > take a stab at writing it up if you'd like. This is a fairly confusing > > aspect of dma-fence behavior. > > We do have some hints in the documentation about that, but nothing which > clearly says "don't expect fences submitted in the order A,B,C to also signal > in order A,B,C unless signaling of each is enabled". > > Were could we add something like that?
Yea, let me take a shot at writing something up. Matt > > Christian. > > > > > Matt
