On Mon, Jun 8, 2026 at 5:33 PM Sami Tolvanen <[email protected]> wrote: > > GpuVm implements Send and Sync unconditionally, but it shares and drops > T::VmBoData and T::Object across threads: obtain() can return ARefs to > the same bo on several threads, and deferred_cleanup() drops them on > whichever thread calls it. This is unsound unless both are Send + Sync, > so bound both impls accordingly.
Sashiko keeps finding more issues here. For the benefit of those not subscribed to dri-devel: > This is a pre-existing issue, but does GpuVm also need Send + Sync bounds > for T::VaData here? > > Since GpuVm<T> explicitly bypasses the lack of Send on VaData, > UniqueRefGpuVm<T> automatically derives Send. This allows safe code to map > a VA containing !Send data on one thread, send the UniqueRefGpuVm<T> to > another thread, and unmap the VA there. > > Unmapping via sm_unmap() returns a GpuVaRemoved<T> which drops the !Send > VaData on the wrong thread, potentially causing data races. Looking at the code, UniqueRefGpuVm seems like a better place for this than GpuVm. However, before I go add another patch to the series, I wonder if it would make more sense to just add these bounds to the DriverGpuVm trait instead? I'd be happy to hear some non-AI thoughts about this too. Sami
