1. 28 10月, 2020 1 次提交
    • D
      drm/shme-helpers: Fix dma_buf_mmap forwarding bug · f49a51bf
      Daniel Vetter 提交于
      When we forward an mmap to the dma_buf exporter, they get to own
      everything. Unfortunately drm_gem_mmap_obj() overwrote
      vma->vm_private_data after the driver callback, wreaking the
      exporter complete. This was noticed because vb2_common_vm_close blew
      up on mali gpu with panfrost after commit 26d3ac3c
      ("drm/shmem-helpers: Redirect mmap for imported dma-buf").
      
      Unfortunately drm_gem_mmap_obj also acquires a surplus reference that
      we need to drop in shmem helpers, which is a bit of a mislayer
      situation. Maybe the entire dma_buf_mmap forwarding should be pulled
      into core gem code.
      
      Note that the only two other drivers which forward mmap in their own
      code (etnaviv and exynos) get this somewhat right by overwriting the
      gem mmap code. But they seem to still have the leak. This might be a
      good excuse to move these drivers over to shmem helpers completely.
      Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
      Acked-by: NChristian König <christian.koenig@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Russell King <linux+etnaviv@armlinux.org.uk>
      Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Joonyoung Shim <jy0922.shim@samsung.com>
      Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Fixes: 26d3ac3c ("drm/shmem-helpers: Redirect mmap for imported dma-buf")
      Cc: Boris Brezillon <boris.brezillon@collabora.com>
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Rob Herring <robh@kernel.org>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-media@vger.kernel.org
      Cc: linaro-mm-sig@lists.linaro.org
      Cc: <stable@vger.kernel.org> # v5.9+
      Reported-and-tested-by: piotr.oniszczuk@gmail.com
      Cc: piotr.oniszczuk@gmail.com
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201027214922.3566743-1-daniel.vetter@ffwll.ch
      f49a51bf
  2. 31 7月, 2020 1 次提交
  3. 28 7月, 2020 1 次提交
  4. 10 6月, 2020 1 次提交
  5. 03 6月, 2020 1 次提交
  6. 20 5月, 2020 6 次提交
  7. 18 5月, 2020 1 次提交
  8. 26 3月, 2020 1 次提交
  9. 18 3月, 2020 1 次提交
  10. 16 3月, 2020 1 次提交
    • C
      drm: Mark up racy check of drm_gem_object.handle_count · 6afe6929
      Chris Wilson 提交于
      [ 1715.899800] BUG: KCSAN: data-race in drm_gem_handle_create_tail / drm_gem_object_handle_put_unlocked
      [ 1715.899838]
      [ 1715.899861] write to 0xffff8881830f3604 of 4 bytes by task 7834 on cpu 1:
      [ 1715.899896]  drm_gem_handle_create_tail+0x62/0x250
      [ 1715.899927]  drm_gem_open_ioctl+0xc1/0x160
      [ 1715.899956]  drm_ioctl_kernel+0xe4/0x120
      [ 1715.899981]  drm_ioctl+0x297/0x4c7
      [ 1715.900003]  ksys_ioctl+0x89/0xb0
      [ 1715.900027]  __x64_sys_ioctl+0x42/0x60
      [ 1715.900052]  do_syscall_64+0x6e/0x2c0
      [ 1715.900079]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [ 1715.900100]
      [ 1715.900119] read to 0xffff8881830f3604 of 4 bytes by task 8137 on cpu 0:
      [ 1715.900149]  drm_gem_object_handle_put_unlocked+0x31/0x130
      [ 1715.900180]  drm_gem_object_release_handle+0x93/0xe0
      [ 1715.900208]  drm_gem_handle_delete+0x7b/0xe0
      [ 1715.900235]  drm_gem_close_ioctl+0x61/0x80
      [ 1715.900264]  drm_ioctl_kernel+0xe4/0x120
      [ 1715.900291]  drm_ioctl+0x297/0x4c7
      [ 1715.900316]  ksys_ioctl+0x89/0xb0
      [ 1715.900340]  __x64_sys_ioctl+0x42/0x60
      [ 1715.900363]  do_syscall_64+0x6e/0x2c0
      [ 1715.900388]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200309120151.7675-1-chris@chris-wilson.co.uk
      6afe6929
  11. 06 12月, 2019 1 次提交
  12. 15 11月, 2019 1 次提交
  13. 30 10月, 2019 1 次提交
  14. 17 10月, 2019 1 次提交
    • G
      drm: add mmap() to drm_gem_object_funcs · c40069cb
      Gerd Hoffmann 提交于
      drm_gem_object_funcs->vm_ops alone can't handle everything which needs
      to be done for mmap(), tweaking vm_flags for example.  So add a new
      mmap() callback to drm_gem_object_funcs where this code can go to.
      
      Note that the vm_ops field is not used in case the mmap callback is
      present, it is expected that the callback sets vma->vm_ops instead.
      
      Also setting vm_flags and vm_page_prot is the job of the new callback.
      so drivers have more control over these flags.
      
      drm_gem_mmap_obj() will use the new callback for object specific mmap
      setup.  With this in place the need for driver-speific fops->mmap
      callbacks goes away, drm_gem_mmap can be hooked instead.
      
      drm_gem_prime_mmap() will use the new callback too to just mmap gem
      objects directly instead of jumping though loops to make
      drm_gem_object_lookup() and fops->mmap work.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-2-kraxel@redhat.com
      c40069cb
  15. 13 8月, 2019 2 次提交
  16. 07 8月, 2019 2 次提交
  17. 05 8月, 2019 1 次提交
  18. 20 7月, 2019 1 次提交
  19. 04 7月, 2019 1 次提交
  20. 29 6月, 2019 1 次提交
  21. 21 6月, 2019 1 次提交
  22. 17 6月, 2019 1 次提交
  23. 28 5月, 2019 1 次提交
  24. 25 4月, 2019 1 次提交
    • S
      drm/gem: Fix sphinx warnings · 761e473f
      Sean Paul 提交于
      Sphinx really wants colons after arguments :/
      
      Fixes the following warnings:
      drm_gem.c:1384: warning: Function parameter or member 'fence_array' not described in 'drm_gem_fence_array_add'
      drm_gem.c:1384: warning: Function parameter or member 'fence' not described in 'drm_gem_fence_array_add'
      drm_gem.c:1435: warning: Function parameter or member 'fence_array' not described in 'drm_gem_fence_array_add_implicit'
      drm_gem.c:1435: warning: Function parameter or member 'obj' not described in 'drm_gem_fence_array_add_implicit'
      drm_gem.c:1435: warning: Function parameter or member 'write' not described in 'drm_gem_fence_array_add_implicit'
      
      Fixes: 5d5a179d ("drm: Add helpers for setting up an array of dma_fence dependencies.")
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Qiang Yu <yuq825@gmail.com> (v1)
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maxime Ripard <maxime.ripard@bootlin.com>
      Cc: Sean Paul <sean@poorly.run>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: dri-devel@lists.freedesktop.org
      Reviewed-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190424204916.222155-1-sean@poorly.run
      761e473f
  25. 17 4月, 2019 1 次提交
  26. 13 4月, 2019 1 次提交
  27. 20 3月, 2019 1 次提交
  28. 15 3月, 2019 1 次提交
  29. 19 2月, 2019 1 次提交
  30. 04 2月, 2019 1 次提交
  31. 10 1月, 2019 1 次提交
  32. 20 11月, 2018 1 次提交
    • N
      drm/gem: Add drm_gem_object_funcs · b39b5394
      Noralf Trønnes 提交于
      This adds an optional function table on GEM objects.
      The main benefit is for drivers that support more than one type of
      memory (shmem,vram,cma) for their buffers depending on the hardware it
      runs on. With the callbacks attached to the GEM object itself, it is
      easier to have core helpers for the the various buffer types. The driver
      only has to make the decision about buffer type on GEM object creation
      and all other callbacks can be handled by the chosen helper.
      
      drm_driver->gem_prime_res_obj has not been added since there's a todo to
      put a reservation_object into drm_gem_object.
      
      v3: Add todo entry
      
      v2: Drop drm_gem_object_funcs->prime_mmap in favour of
      drm_gem_prime_mmap() (Daniel Vetter)
      
      v1:
      - drm_gem_object_funcs.map -> .prime_map let it only do PRIME mmap like
        the function it superseeds (Daniel Vetter)
      - Flip around the if ladders and make obj->funcs the first choice
        highlighting the fact that this the new default way of doing it
        (Daniel Vetter)
      Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: NChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181110145647.17580-4-noralf@tronnes.org
      b39b5394
  33. 15 9月, 2018 1 次提交
    • C
      drm: Differentiate the lack of an interface from invalid parameter · 69fdf420
      Chris Wilson 提交于
      If the ioctl is not supported on a particular piece of HW/driver
      combination, report ENOTSUP (aka EOPNOTSUPP) so that it can be easily
      distinguished from both the lack of the ioctl and from a regular invalid
      parameter.
      
      v2: Across all the kms ioctls we had a mixture of reporting EINVAL,
      ENODEV and a few ENOTSUPP (most where EINVAL) for a failed
      drm_core_check_feature(). Update everybody to report ENOTSUPP.
      
      v3: ENOTSUPP is an internal errno! It's value (524) does not correspond
      to a POSIX errno, the one we want is ENOTSUP. However,
      uapi/asm-generic/errno.h doesn't include ENOTSUP but man errno says
      
      	"ENOTSUP and EOPNOTSUPP have the same value on Linux,
      	but according to POSIX.1 these error values should be
      	distinct."
      
      so use EOPNOTSUPP as its equivalent.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v2
      Link: https://patchwork.freedesktop.org/patch/msgid/20180913192050.24812-1-chris@chris-wilson.co.uk
      69fdf420