Question about page table updates at BO destroy

[Nicolai Hähnle]

Hi Jerry,

On 23.03.2017 03:26, Zhang, Jerry (Junwei) wrote:
> 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?

I'm thinking of the scenario without an unmap, i.e. broken / malicious 
user space. I haven't looked into the unmap case, I will. I have a WIP 
patch for this, will give it a proper test drive later.

Cheers,
Nicolai


>
> 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.