Re: Question about page table updates at BO destroy

["Zhang, Jerry (Junwei)" <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>]

On 03/22/2017 11:06 PM, Nicolai Hähnle wrote:
> 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.

The user space should call unmap when free a BO, as my understanding.
In this case, it will call amdgpu_gem_va_update_vm() to clear the PTE related 
to the BO.
Right?

Or you just imagine this scenery that there is no unmap?

Jerry

> 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx