linux/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c, branch v5.17

Revert "drm/amdgpu: Don't inherit GEM object VMAs in child process"

2022-01-11T20:44:27Z

This reverts commit fbcdbfde87509d523132b59f661a355c731139d0. Reviewed-by: Felix Kuehling Signed-off-by: Rajneesh Bhardwaj Signed-off-by: Alex Deucher

drm/amdgpu: Don't inherit GEM object VMAs in child process

2021-12-28T21:03:08Z

When an application having open file access to a node forks, its shared mappings also get reflected in the address space of child process even though it cannot access them with the object permissions applied. With the existing permission checks on the gem objects, it might be reasonable to also create the VMAs with VM_DONTCOPY flag so a user space application doesn't need to explicitly call the madvise(addr, len, MADV_DONTFORK) system call to prevent the pages in the mapped range to appear in the address space of the child process. It also prevents the memory leaks due to additional reference counts on the mapped BOs in the child process that prevented freeing the memory in the parent for which we had worked around earlier in the user space inside the thunk library. Additionally, we faced this issue when using CRIU to checkpoint restore an application that had such inherited mappings in the child which confuse CRIU when it mmaps on restore. Having this flag set for the render node VMAs helps. VMAs mapped via KFD already take care of this so this is needed only for the render nodes. To limit the impact of the change to user space consumers such as OpenGL etc, limit it to KFD BOs only. Acked-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: David Yat Sin Signed-off-by: Rajneesh Bhardwaj Signed-off-by: Alex Deucher

drm/amdgpu: update the domain flags for dumb buffer creation

2021-11-24T19:06:53Z

After switching to generic framebuffer framework, we rely on the ->dumb_create routine for frame buffer creation. However, the different domain flags used are not optimal. Add the contiguous flag to directly allocate the scanout BO as one linear buffer. Fixes: 087451f372bf76 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.") Signed-off-by: Evan Quan Reviewed-by: Christian König Reviewed-by: Guchun Chen Signed-off-by: Alex Deucher

drm/amdgpu: use generic fb helpers instead of setting up AMD own's.

2021-11-17T21:58:03Z

With the shadow buffer support from generic framebuffer emulation, it's possible now to have runpm kicked when no update for console. Signed-off-by: Evan Quan Acked-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/ttm: remove ttm_bo_vm_insert_huge()

2021-11-05T10:13:19Z

The huge page functionality in TTM does not work safely because PUD and PMD entries do not have a special bit. get_user_pages_fast() considers any page that passed pmd_huge() as usable: if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) || pmd_devmap(pmd))) { And vmf_insert_pfn_pmd_prot() unconditionally sets entry = pmd_mkhuge(pfn_t_pmd(pfn, prot)); eg on x86 the page will be _PAGE_PRESENT | PAGE_PSE. As such gup_huge_pmd() will try to deref a struct page: head = try_grab_compound_head(pmd_page(orig), refs, flags); and thus crash. Thomas further notices that the drivers are not expecting the struct page to be used by anything - in particular the refcount incr above will cause them to malfunction. Thus everything about this is not able to fully work correctly considering GUP_fast. Delete it entirely. It can return someday along with a proper PMD/PUD_SPECIAL bit in the page table itself to gate GUP_fast. Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults") Signed-off-by: Jason Gunthorpe Reviewed-by: Thomas Hellström Reviewed-by: Christian König [danvet: Update subject per Thomas' &Christian's review] Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/0-v2-a44694790652+4ac-ttm_pmd_jgg@nvidia.com

drm/amdgpu: Fix a deadlock if previous GEM object allocation fails

2021-08-31T18:20:08Z

Fall through to handle the error instead of return. Fixes: f8aab60422c37 ("drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs") Cc: stable@vger.kernel.org Signed-off-by: xinhui pan Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: rename amdgpu_bo_get_preferred_pin_domain

2021-08-25T22:15:17Z

amdgpu_bo_get_preferred_pin_domain is used for page tables creation, which is not involved with page pinning. And it is used in more cases than display scanout, modify its documentation as well. Signed-off-by: Yifan Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher

Revert "Revert "drm/amdgpu: Add table_freed parameter to amdgpu_vm_bo_update""

2021-08-02T21:21:24Z

This reverts commit 024d8811c90ed56d8b90cdcf71e51c9fedeff460. Revert reason: The issue has been resolved. Signed-off-by: Eric Huang Signed-off-by: Alex Deucher

Backmerge tag 'v5.14-rc3' into drm-next

2021-07-25T23:27:59Z

Linux 5.14-rc3 Daniel said we should pull the nouveau fix from fixes in here, probably a good plan. Signed-off-by: Dave Airlie

Merge tag 'drm-misc-fixes-2021-07-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

2021-07-23T01:17:03Z

Short summary of fixes pull: * Return -ENOTTY for non-DRM ioctls * amdgpu: Fix COW checks * nouveau: init BO GME fields * panel: Avoid double free * ttm: Fix refcounting in ttm_global_init(); NULL checks * vc4: Fix interrupt handling Signed-off-by: Dave Airlie From: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/YPlbkmH6S4VAHP9j@linux-uq9g.fritz.box