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? Christian. > > Matt
