Question about page table updates at BO destroy

Nicolai Hähnle nhaehnle at
Thu Mar 23 13:07:43 UTC 2017

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.


> 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

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

More information about the amd-gfx mailing list