1. 24 8月, 2019 5 次提交
    • R
      drm/shmem: Use mutex_trylock in drm_gem_shmem_purge · dfbc7a46
      Rob Herring 提交于
      Lockdep reports a circular locking dependency with pages_lock taken in
      the shrinker callback. The deadlock can't actually happen with current
      users at least as a BO will never be purgeable when pages_lock is held.
      To be safe, let's use mutex_trylock() instead and bail if a BO is locked
      already.
      
      WARNING: possible circular locking dependency detected
      5.3.0-rc1+ #100 Tainted: G             L
      ------------------------------------------------------
      kswapd0/171 is trying to acquire lock:
      000000009b9823fd (&shmem->pages_lock){+.+.}, at: drm_gem_shmem_purge+0x20/0x40
      
      but task is already holding lock:
      00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (fs_reclaim){+.+.}:
             fs_reclaim_acquire.part.18+0x34/0x40
             fs_reclaim_acquire+0x20/0x28
             __kmalloc_node+0x6c/0x4c0
             kvmalloc_node+0x38/0xa8
             drm_gem_get_pages+0x80/0x1d0
             drm_gem_shmem_get_pages+0x58/0xa0
             drm_gem_shmem_get_pages_sgt+0x48/0xd0
             panfrost_mmu_map+0x38/0xf8 [panfrost]
             panfrost_gem_open+0xc0/0xe8 [panfrost]
             drm_gem_handle_create_tail+0xe8/0x198
             drm_gem_handle_create+0x3c/0x50
             panfrost_gem_create_with_handle+0x70/0xa0 [panfrost]
             panfrost_ioctl_create_bo+0x48/0x80 [panfrost]
             drm_ioctl_kernel+0xb8/0x110
             drm_ioctl+0x244/0x3f0
             do_vfs_ioctl+0xbc/0x910
             ksys_ioctl+0x78/0xa8
             __arm64_sys_ioctl+0x1c/0x28
             el0_svc_common.constprop.0+0x90/0x168
             el0_svc_handler+0x28/0x78
             el0_svc+0x8/0xc
      
      -> #0 (&shmem->pages_lock){+.+.}:
             __lock_acquire+0xa2c/0x1d70
             lock_acquire+0xdc/0x228
             __mutex_lock+0x8c/0x800
             mutex_lock_nested+0x1c/0x28
             drm_gem_shmem_purge+0x20/0x40
             panfrost_gem_shrinker_scan+0xc0/0x180 [panfrost]
             do_shrink_slab+0x208/0x500
             shrink_slab+0x10c/0x2c0
             shrink_node+0x28c/0x4d8
             balance_pgdat+0x2c8/0x570
             kswapd+0x22c/0x638
             kthread+0x128/0x130
             ret_from_fork+0x10/0x18
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(fs_reclaim);
                                     lock(&shmem->pages_lock);
                                     lock(fs_reclaim);
        lock(&shmem->pages_lock);
      
       *** DEADLOCK ***
      
      3 locks held by kswapd0/171:
       #0: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40
       #1: 00000000ceb37808 (shrinker_rwsem){++++}, at: shrink_slab+0xbc/0x2c0
       #2: 00000000f31efa81 (&pfdev->shrinker_lock){+.+.}, at: panfrost_gem_shrinker_scan+0x34/0x180 [panfrost]
      
      Fixes: 17acb9f3 ("drm/shmem: Add madvise state and purge helpers")
      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>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Acked-by: NAlyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190823021216.5862-6-robh@kernel.org
      dfbc7a46
    • R
      drm/shmem: Do dma_unmap_sg before purging pages · 4fa3d66f
      Rob Herring 提交于
      Calling dma_unmap_sg() in drm_gem_shmem_free_object() is too late if the
      backing pages have already been released by the shrinker. The result is
      the following abort:
      
      Unable to handle kernel paging request at virtual address ffff8000098ed000
      Mem abort info:
        ESR = 0x96000147
        Exception class = DABT (current EL), IL = 32 bits
        SET = 0, FnV = 0
        EA = 0, S1PTW = 0
      Data abort info:
        ISV = 0, ISS = 0x00000147
        CM = 1, WnR = 1
      swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000002f51000
      [ffff8000098ed000] pgd=00000000401f8003, pud=00000000401f7003, pmd=00000000401b1003, pte=00e80000098ed712
      Internal error: Oops: 96000147 [#1] SMP
      Modules linked in: panfrost gpu_sched
      CPU: 5 PID: 902 Comm: gnome-shell Not tainted 5.3.0-rc1+ #95
      Hardware name: 96boards Rock960 (DT)
      pstate: 40000005 (nZcv daif -PAN -UAO)
      pc : __dma_inv_area+0x40/0x58
      lr : arch_sync_dma_for_cpu+0x28/0x30
      sp : ffff00001321ba30
      x29: ffff00001321ba30 x28: ffff00001321bd08
      x27: 0000000000000000 x26: 0000000000000009
      x25: 0000ffffc1f86170 x24: 0000000000000000
      x23: 0000000000000000 x22: 0000000000000000
      x21: 0000000000021000 x20: ffff80003bb2d810
      x19: 00000000098ed000 x18: 0000000000000000
      x17: 0000000000000000 x16: ffff800023fd9480
      x15: 0000000000000000 x14: 0000000000000000
      x13: 0000000000000000 x12: 0000000000000000
      x11: 00000000fffb9fff x10: 0000000000000000
      x9 : 0000000000000000 x8 : ffff800023fd9c18
      x7 : 0000000000000000 x6 : 00000000ffffffff
      x5 : 0000000000000000 x4 : 0000000000021000
      Purging 5693440 bytes
      x3 : 000000000000003f x2 : 0000000000000040
      x1 : ffff80000990e000 x0 : ffff8000098ed000
      Call trace:
       __dma_inv_area+0x40/0x58
       dma_direct_sync_single_for_cpu+0x7c/0x80
       dma_direct_unmap_page+0x80/0x88
       dma_direct_unmap_sg+0x54/0x80
       drm_gem_shmem_free_object+0xfc/0x108
       panfrost_gem_free_object+0x118/0x128 [panfrost]
       drm_gem_object_free+0x18/0x90
       drm_gem_object_put_unlocked+0x58/0x80
       drm_gem_object_handle_put_unlocked+0x64/0xb0
       drm_gem_object_release_handle+0x70/0x98
       drm_gem_handle_delete+0x64/0xb0
       drm_gem_close_ioctl+0x28/0x38
       drm_ioctl_kernel+0xb8/0x110
       drm_ioctl+0x244/0x3f0
       do_vfs_ioctl+0xbc/0x910
       ksys_ioctl+0x78/0xa8
       __arm64_sys_ioctl+0x1c/0x28
       el0_svc_common.constprop.0+0x88/0x150
       el0_svc_handler+0x28/0x78
       el0_svc+0x8/0xc
       Code: 8a230000 54000060 d50b7e20 14000002 (d5087620)
      
      Fixes: 17acb9f3 ("drm/shmem: Add madvise state and purge helpers")
      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>
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Acked-by: NAlyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190823021216.5862-5-robh@kernel.org
      4fa3d66f
    • R
      drm/panfrost: Fix possible suspend in panfrost_remove · 593bc4d0
      Rob Herring 提交于
      Calls to panfrost_device_fini() access the h/w, but we already done a
      pm_runtime_put_sync_autosuspend() beforehand. This only works if the
      autosuspend delay is long enough. A 0ms delay will hang the system when
      removing the device. Fix this by moving the pm_runtime_put_sync_suspend()
      after the panfrost_device_fini() call.
      
      Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Acked-by: NAlyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190823021216.5862-2-robh@kernel.org
      593bc4d0
    • R
      MAINTAINERS: Add Steven and Alyssa as panfrost reviewers · 97588c89
      Rob Herring 提交于
      Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
      primary reviewers already.
      
      Cc: Steven Price <steven.price@arm.com>
      Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
      Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NSteven Price <steven.price@arm.com>
      Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
      Reviewed-by: NAlyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190823013357.932-1-robh@kernel.org
      97588c89
    • S
      drm/panfrost: Add missing check for pfdev->regulator · 52282163
      Steven Price 提交于
      When modifying panfrost_devfreq_target() to support a device without a
      regulator defined I missed the check on the error path. Let's add it.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Fixes: e21dd290 ("drm/panfrost: Enable devfreq to work without regulator")
      Signed-off-by: NSteven Price <steven.price@arm.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190822093218.26014-1-steven.price@arm.com
      52282163
  2. 23 8月, 2019 6 次提交
  3. 22 8月, 2019 27 次提交
  4. 21 8月, 2019 1 次提交
  5. 20 8月, 2019 1 次提交