(+Cc Daniel) On Mon, 2026-06-22 at 14:17 +0200, Christian König wrote: > On 6/22/26 10:57, Philipp Stanner wrote: > > > > The issue Dave addressed was a UAF within Nouveau itself, where the > > driver put() its own fence while its own callbacks were still > > executing. > > Yeah that's exactly the reason why I have been rejecting the idea > that drivers install callbacks on their own fences.
I remember we had that discussion when I discovered that signaled fences can temporarily remain on nouveau's "unsignaled fences" list and wanted to do the removal automatically via callback. > > Maybe an idea how to generally tackle this for all drivers: Never let > the dma-fence framework call dma_fence_signal(), that should only the > driver do by itself. About the framework I'm not sure, but what we do enforce strictly in Rust is that only the creator of a fence can signal it. We achieve that by two fence types, of which only one implements a signal() method I remember seeing some parties signaling the GPU scheduler's fences, so such things definitely happen. And since you likely can't enforce it in C, you would still have to take the possibility of a third party signalling your fence into account. > > This way we don't run into the issue in the first place that the > driver needs to install some callbacks *and* the driver also knows > when the installed callbacks are finished because that is when > dma_fence_signal() returns. > > Does that sound valid to you guys? If yes I will be sending out > patches to do this. Hm. I suppose that would be an improvement? Maybe let me ask differently, too: why is it that the framework is signaling fences in the first place? If I understood you correctly last time that is partially related to the locking problem in the callbacks. P. > > Regards, > Christian.
