On 2025-05-28 14:14, Paneer Selvam, Arunpravin wrote: > On 5/28/2025 2:59 PM, Natalie Vock wrote: >> On 5/28/25 09:07, Christian König wrote: >>> >>> But the problem rather seems to be that we sometimes don't clear the >>> buffers on release for some reason, but still set it as cleared. >> >> Yes precisely - "some reason" being the aforementioned clear flags. We do >> always call amdgpu_clear_buffer on release, but that function will perform >> the same checks as the clear on allocation does - that means, if a block is >> marked clear then it will skip emitting any actual clears. > > On buffer release > [https://elixir.bootlin.com/linux/v6.15/source/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c#L1318], > we call amdgpu_fill_buffer() and not amdgpu_clear_buffer() (in > amdgpu_bo_release_notify() function), so the buffers are expected to be > cleared without fail. > > When the user space doesn't set the AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE > flag and having only AMDGPU_GEM_CREATE_VRAM_CLEARED, we don't call this > amdgpu_fill_buffer() and amdgpu_vram_mgr_set_cleared(), and that's kind of > makes sense. > I think the problem here is, when we don't clear the buffer during BO > release, but the flag remains as cleared and that's why these blocks are > skipped during clear on allocation (in amdgpu_bo_create() function). > > Therefore, if the release path clear is skipped for any reasons (for example, > in case of AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE not set), we should set all > buffer to dirty. Somehow, that is missed. BTW, I asked this before, but didn't get an answer:
Now that VRAM is always cleared before handing it out to user space, does AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE really need to do anything anymore? How can user space access the contents of a destroyed BO? -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
