On 2/10/26 10:06, Philipp Stanner wrote: > On Tue, 2026-02-10 at 08:38 +0000, Alice Ryhl wrote: >> On Tue, Feb 10, 2026 at 09:16:34AM +0100, Christian König wrote: >>> >>> >>> On the C side I have a patch set which does something very similar. >>> >>> It's basically a WARN_ON_ONCE() which triggers as soon as you try to >>> signal a DMA fence from an IOCTL, or more specific process context. >>> >>> Signaling a DMA fence from interrupt context, a work item or kernel >>> thread is still allowed, there is just the hole that you can schedule >>> a work item from process context as well. >>> >>> The major problem with that patch set is that we have tons of very >>> hacky signaling paths in drivers already because we initially didn't >>> knew how much trouble getting this wrong causes. >>> >>> I'm strongly in favor of getting this right for the rust side from the >>> beginning and enforcing strict rules for every code trying to >>> implement a DMA fence. >> >> Hmm. Could you say a bit more about what the rules are? I just re-read >> the comments in dma-fence.c, but I have some questions. > > The rules need to be written down. Elaborately and in detail, once and > for all. > > We're having those discussions about the mysterious "dma fence rules" > for years, but no one has ever seen them, despite knowing that they > exist.
Well we have this here: https://kernel.org/doc/html/v5.9/driver-api/dma-buf.html#indefinite-dma-fences > They seem to live only in the heads of a small number of GPU developers > who figured out through long years of experience what works and what > doesn't. It's not even experience you need for that. I've pointed out the problems we would have with this even before the original dma_fence patches were merged. You just have a very very small number of people who sees the design and immediately realize what that means, while everybody else even with documentation doesn't seem to get the full consequences. > There are reasons why the state writes the laws on paper somewhere. So > that you can read them and have a source of authority.. Yeah but you also have an executive who enforces those laws. At some point you just give up on explaining the background. I think it would help massively when lockdep could point out even more problematic approaches. > That would end much of our endless misunderstandings and repetitive > discussions. You won't believe how graceful I would be if we could somehow improve the situation. I've literally had to explain to whole teams who spend men years on developing something that their approach is flawed and they can throw away all their work because of those dma_fence limitations here. This is a repeating pattern which happens at least once or twice a year. Regards, Christian. > > > P.
