Hi Nicolai, yeah, that is a known issue. You don't necessary need to add all fences from the PD to the released BO, but immediately starting to clear the PTE would be a good idea. amdgpu_gem_object_close() should call amdgpu_vm_clear_freed() if the PD/PT are swapped in at that moment. This leaves only a very small window where the application could access freed up memory while the PTEs are cleared. If we even want to close that one we could let amdgpu_vm_clear_freed() return the fence of the clear operation and add that to the BO in question. Regards, Christian. Am 22.03.2017 um 16:06 schrieb Nicolai Hähnle: > Hi all, > > there's a bit of a puzzle where I'm wondering whether there's a subtle > bug in the amdgpu kernel module. > > Basically, the concern is that a buggy user space driver might trigger > a sequence like this: > > 1. Submit a CS that accesses some BO _without_ adding that BO to the > buffer list. > 2. Free that BO. > 3. Some other task re-uses the memory underlying the BO. > 4. The CS is submitted to the hardware and accesses memory that is now > already in use by somebody else, since there has been no update to the > page tables to reflect the freed BO. > > Obviously there's a user space bug in step 1, but the kernel must > still prevent the conflicting memory accesses, and I don't see where > it does. > > amdgpu_gem_object_close takes a reservation of the BO and the page > directory, but then simply backs off that reservation rather than > adding a fence, which I suspect is necessary. > > I believe that whenever we remove a BO from a VM, we must > unconditionally add the most recent page directory fence(?) to the BO. > Does that sound right? > > Cheers, > Nicolai > > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
