1. 11 11月, 2022 1 次提交
  2. 10 11月, 2022 1 次提交
    • P
      drm/amdgpu: Unlock bo_list_mutex after error handling · c70e2166
      Philip Yang 提交于
      Get below kernel WARNING backtrace when pressing ctrl-C to kill kfdtest
      application.
      
      If amdgpu_cs_parser_bos returns error after taking bo_list_mutex, as
      caller amdgpu_cs_ioctl will not unlock bo_list_mutex, this generates the
      kernel WARNING.
      
      Add unlock bo_list_mutex after amdgpu_cs_parser_bos error handling to
      cleanup bo_list userptr bo.
      
       WARNING: kfdtest/2930 still has locks held!
       1 lock held by kfdtest/2930:
        (&list->bo_list_mutex){+.+.}-{3:3}, at: amdgpu_cs_ioctl+0xce5/0x1f10 [amdgpu]
        stack backtrace:
         dump_stack_lvl+0x44/0x57
         get_signal+0x79f/0xd00
         arch_do_signal_or_restart+0x36/0x7b0
         exit_to_user_mode_prepare+0xfd/0x1b0
         syscall_exit_to_user_mode+0x19/0x40
         do_syscall_64+0x40/0x80
      Signed-off-by: NPhilip Yang <Philip.Yang@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      c70e2166
  3. 21 9月, 2022 2 次提交
  4. 20 9月, 2022 3 次提交
  5. 14 9月, 2022 5 次提交
  6. 17 8月, 2022 1 次提交
    • M
      drm/amdgpu: Fix use-after-free on amdgpu_bo_list mutex · bbca24d0
      Maíra Canal 提交于
      If amdgpu_cs_vm_handling returns r != 0, then it will unlock the
      bo_list_mutex inside the function amdgpu_cs_vm_handling and again on
      amdgpu_cs_parser_fini. This problem results in the following
      use-after-free problem:
      
      [ 220.280990] ------------[ cut here ]------------
      [ 220.281000] refcount_t: underflow; use-after-free.
      [ 220.281019] WARNING: CPU: 1 PID: 3746 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
      [ 220.281029] ------------[ cut here ]------------
      [ 220.281415] CPU: 1 PID: 3746 Comm: chrome:cs0 Tainted: G W L ------- --- 5.20.0-0.rc0.20220812git7ebfc85e.10.fc38.x86_64 #1
      [ 220.281421] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022
      [ 220.281426] RIP: 0010:refcount_warn_saturate+0xba/0x110
      [ 220.281431] Code: 01 01 e8 79 4a 6f 00 0f 0b e9 42 47 a5 00 80 3d de
      7e be 01 00 75 85 48 c7 c7 f8 98 8e 98 c6 05 ce 7e be 01 01 e8 56 4a
      6f 00 <0f> 0b e9 1f 47 a5 00 80 3d b9 7e be 01 00 0f 85 5e ff ff ff 48
      c7
      [ 220.281437] RSP: 0018:ffffb4b0d18d7a80 EFLAGS: 00010282
      [ 220.281443] RAX: 0000000000000026 RBX: 0000000000000003 RCX: 0000000000000000
      [ 220.281448] RDX: 0000000000000001 RSI: ffffffff988d06dc RDI: 00000000ffffffff
      [ 220.281452] RBP: 00000000ffffffff R08: 0000000000000000 R09: ffffb4b0d18d7930
      [ 220.281457] R10: 0000000000000003 R11: ffffa0672e2fffe8 R12: ffffa058ca360400
      [ 220.281461] R13: ffffa05846c50a18 R14: 00000000fffffe00 R15: 0000000000000003
      [ 220.281465] FS: 00007f82683e06c0(0000) GS:ffffa066e2e00000(0000) knlGS:0000000000000000
      [ 220.281470] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 220.281475] CR2: 00003590005cc000 CR3: 00000001fca46000 CR4: 0000000000350ee0
      [ 220.281480] Call Trace:
      [ 220.281485] <TASK>
      [ 220.281490] amdgpu_cs_ioctl+0x4e2/0x2070 [amdgpu]
      [ 220.281806] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
      [ 220.282028] drm_ioctl_kernel+0xa4/0x150
      [ 220.282043] drm_ioctl+0x21f/0x420
      [ 220.282053] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
      [ 220.282275] ? lock_release+0x14f/0x460
      [ 220.282282] ? _raw_spin_unlock_irqrestore+0x30/0x60
      [ 220.282290] ? _raw_spin_unlock_irqrestore+0x30/0x60
      [ 220.282297] ? lockdep_hardirqs_on+0x7d/0x100
      [ 220.282305] ? _raw_spin_unlock_irqrestore+0x40/0x60
      [ 220.282317] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu]
      [ 220.282534] __x64_sys_ioctl+0x90/0xd0
      [ 220.282545] do_syscall_64+0x5b/0x80
      [ 220.282551] ? futex_wake+0x6c/0x150
      [ 220.282568] ? lock_is_held_type+0xe8/0x140
      [ 220.282580] ? do_syscall_64+0x67/0x80
      [ 220.282585] ? lockdep_hardirqs_on+0x7d/0x100
      [ 220.282592] ? do_syscall_64+0x67/0x80
      [ 220.282597] ? do_syscall_64+0x67/0x80
      [ 220.282602] ? lockdep_hardirqs_on+0x7d/0x100
      [ 220.282609] entry_SYSCALL_64_after_hwframe+0x63/0xcd
      [ 220.282616] RIP: 0033:0x7f8282a4f8bf
      [ 220.282639] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10
      00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00
      0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00
      00
      [ 220.282644] RSP: 002b:00007f82683df410 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [ 220.282651] RAX: ffffffffffffffda RBX: 00007f82683df588 RCX: 00007f8282a4f8bf
      [ 220.282655] RDX: 00007f82683df4d0 RSI: 00000000c0186444 RDI: 0000000000000018
      [ 220.282659] RBP: 00007f82683df4d0 R08: 00007f82683df5e0 R09: 00007f82683df4b0
      [ 220.282663] R10: 00001d04000a0600 R11: 0000000000000246 R12: 00000000c0186444
      [ 220.282667] R13: 0000000000000018 R14: 00007f82683df588 R15: 0000000000000003
      [ 220.282689] </TASK>
      [ 220.282693] irq event stamp: 6232311
      [ 220.282697] hardirqs last enabled at (6232319): [<ffffffff9718cd7e>] __up_console_sem+0x5e/0x70
      [ 220.282704] hardirqs last disabled at (6232326): [<ffffffff9718cd63>] __up_console_sem+0x43/0x70
      [ 220.282709] softirqs last enabled at (6232072): [<ffffffff970ff669>] __irq_exit_rcu+0xf9/0x170
      [ 220.282716] softirqs last disabled at (6232061): [<ffffffff970ff669>] __irq_exit_rcu+0xf9/0x170
      [ 220.282722] ---[ end trace 0000000000000000 ]---
      
      Therefore, remove the mutex_unlock from the amdgpu_cs_vm_handling
      function, so that amdgpu_cs_submit and amdgpu_cs_parser_fini can handle
      the unlock.
      
      Fixes: 90af0ca0 ("drm/amdgpu: Protect the amdgpu_bo_list list with a mutex v2")
      Reported-by: NMikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Reviewed-by: NMelissa Wen <mwen@igalia.com>
      Signed-off-by: NMaíra Canal <mairacanal@riseup.net>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      bbca24d0
  7. 21 7月, 2022 2 次提交
  8. 27 5月, 2022 2 次提交
    • D
      drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. · 31ab27b1
      Dave Airlie 提交于
      Submitting a cs with 0 chunks, causes an oops later, found trying
      to execute the wrong userspace driver.
      
      MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo
      
      [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8
      [172536.665188] #PF: supervisor read access in kernel mode
      [172536.665189] #PF: error_code(0x0000) - not-present page
      [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0
      [172536.665195] Oops: 0000 [#1] SMP NOPTI
      [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P           O      5.10.81 #1-NixOS
      [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015
      [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu]
      [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10
      [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246
      [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68
      [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38
      [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40
      [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28
      [172536.665283] FS:  00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000
      [172536.665284] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0
      [172536.665287] Call Trace:
      [172536.665322]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
      [172536.665332]  drm_ioctl_kernel+0xaa/0xf0 [drm]
      [172536.665338]  drm_ioctl+0x201/0x3b0 [drm]
      [172536.665369]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
      [172536.665372]  ? selinux_file_ioctl+0x135/0x230
      [172536.665399]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
      [172536.665403]  __x64_sys_ioctl+0x83/0xb0
      [172536.665406]  do_syscall_64+0x33/0x40
      [172536.665409]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018Signed-off-by: NDave Airlie <airlied@redhat.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      31ab27b1
    • C
      drm/amdgpu: cleanup ctx implementation · 69493c03
      Christian König 提交于
      Let each context have a pointer to the ctx manager and properly
      initialize the adev pointer inside the context manager.
      
      Reduce the BUG_ON() in amdgpu_ctx_add_fence() into a WARN_ON() and
      directly return the sequence number instead of writing into a parmeter.
      Signed-off-by: NChristian König <christian.koenig@amd.com>
      Reviewed-by: NShashank Sharma <shashank.sharma@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      69493c03
  9. 04 5月, 2022 1 次提交
  10. 29 4月, 2022 1 次提交
  11. 21 4月, 2022 1 次提交
  12. 07 4月, 2022 3 次提交
  13. 04 4月, 2022 1 次提交
  14. 26 3月, 2022 2 次提交
  15. 16 3月, 2022 1 次提交
  16. 10 3月, 2022 1 次提交
  17. 05 3月, 2022 2 次提交
  18. 14 2月, 2022 1 次提交
  19. 12 2月, 2022 1 次提交
    • K
      drm/amdgpu: remove ctx->lock · 461fa7b0
      Ken Xue 提交于
      KMD reports a warning on holding a lock from drm_syncobj_find_fence,
      when running amdgpu_test case “syncobj timeline test”.
      
      ctx->lock was designed to prevent concurrent "amdgpu_ctx_wait_prev_fence"
      calls and avoid dead reservation lock from GPU reset. since no reservation
      lock is held in latest GPU reset any more, ctx->lock can be simply removed
      and concurrent "amdgpu_ctx_wait_prev_fence" call also can be prevented by
      PD root bo reservation lock.
      
      call stacks:
      =================
      //hold lock
      amdgpu_cs_ioctl->amdgpu_cs_parser_init->mutex_lock(&parser->ctx->lock);
      …
      //report warning
      amdgpu_cs_dependencies->amdgpu_cs_process_syncobj_timeline_in_dep \
      ->amdgpu_syncobj_lookup_and_add_to_sync -> drm_syncobj_find_fence \
      -> lockdep_assert_none_held_once
      …
      amdgpu_cs_ioctl->amdgpu_cs_parser_fini->mutex_unlock(&parser->ctx->lock);
      Signed-off-by: NKen Xue <Ken.Xue@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      461fa7b0
  20. 26 1月, 2022 1 次提交
  21. 19 1月, 2022 1 次提交
  22. 12 1月, 2022 1 次提交
  23. 30 8月, 2021 2 次提交
    • D
      drm/sched: drop entity parameter from drm_sched_push_job · 0e10e9a1
      Daniel Vetter 提交于
      Originally a job was only bound to the queue when we pushed this, but
      now that's done in drm_sched_job_init, making that parameter entirely
      redundant.
      
      Remove it.
      
      The same applies to the context parameter in
      lima_sched_context_queue_task, simplify that too.
      
      v2:
      Rebase on top of msm adopting drm/sched
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Acked-by: NEmma Anholt <emma@anholt.net>
      Acked-by: NMelissa Wen <mwen@igalia.com>
      Reviewed-by: Steven Price <steven.price@arm.com> (v1)
      Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> (v1)
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Russell King <linux+etnaviv@armlinux.org.uk>
      Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
      Cc: Qiang Yu <yuq825@gmail.com>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
      Cc: Steven Price <steven.price@arm.com>
      Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
      Cc: Emma Anholt <emma@anholt.net>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: "Christian König" <christian.koenig@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Nirmoy Das <nirmoy.das@amd.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Chen Li <chenli@uniontech.com>
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Deepak R Varma <mh12gx2825@gmail.com>
      Cc: Kevin Wang <kevin1.wang@amd.com>
      Cc: Luben Tuikov <luben.tuikov@amd.com>
      Cc: "Marek Olšák" <marek.olsak@amd.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
      Cc: Dennis Li <Dennis.Li@amd.com>
      Cc: Boris Brezillon <boris.brezillon@collabora.com>
      Cc: etnaviv@lists.freedesktop.org
      Cc: lima@lists.freedesktop.org
      Cc: linux-media@vger.kernel.org
      Cc: linaro-mm-sig@lists.linaro.org
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Sean Paul <sean@poorly.run>
      Cc: Melissa Wen <mwen@igalia.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20210805104705.862416-6-daniel.vetter@ffwll.ch
      0e10e9a1
    • D
      drm/sched: Split drm_sched_job_init · dbe48d03
      Daniel Vetter 提交于
      This is a very confusingly named function, because not just does it
      init an object, it arms it and provides a point of no return for
      pushing a job into the scheduler. It would be nice if that's a bit
      clearer in the interface.
      
      But the real reason is that I want to push the dependency tracking
      helpers into the scheduler code, and that means drm_sched_job_init
      must be called a lot earlier, without arming the job.
      
      v2:
      - don't change .gitignore (Steven)
      - don't forget v3d (Emma)
      
      v3: Emma noticed that I leak the memory allocated in
      drm_sched_job_init if we bail out before the point of no return in
      subsequent driver patches. To be able to fix this change
      drm_sched_job_cleanup() so it can handle being called both before and
      after drm_sched_job_arm().
      
      Also improve the kerneldoc for this.
      
      v4:
      - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as
        usual (Melissa)
      
      - Christian pointed out that drm_sched_entity_select_rq() also needs
        to be moved into drm_sched_job_arm, which made me realize that the
        job->id definitely needs to be moved too.
      
        Shuffle things to fit between job_init and job_arm.
      
      v5:
      Reshuffle the split between init/arm once more, amdgpu abuses
      drm_sched.ready to signal gpu reset failures. Also document this
      somewhat. (Christian)
      
      v6:
      Rebase on top of the msm drm/sched support. Note that the
      drm_sched_job_init() call is completely misplaced, and hence also the
      split-out drm_sched_entity_push_job(). I've put in a FIXME which the next
      patch will address.
      
      v7: Drop the FIXME in msm, after discussions with Rob I agree it shouldn't
      be a problem where it is now.
      Acked-by: NChristian König <christian.koenig@amd.com>
      Acked-by: NMelissa Wen <mwen@igalia.com>
      Cc: Melissa Wen <melissa.srw@gmail.com>
      Acked-by: NEmma Anholt <emma@anholt.net>
      Acked-by: Steven Price <steven.price@arm.com> (v2)
      Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> (v5)
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Russell King <linux+etnaviv@armlinux.org.uk>
      Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
      Cc: Qiang Yu <yuq825@gmail.com>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
      Cc: Steven Price <steven.price@arm.com>
      Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: "Christian König" <christian.koenig@amd.com>
      Cc: Masahiro Yamada <masahiroy@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Adam Borowski <kilobyte@angband.pl>
      Cc: Nick Terrell <terrelln@fb.com>
      Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Cc: Paul Menzel <pmenzel@molgen.mpg.de>
      Cc: Sami Tolvanen <samitolvanen@google.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Nirmoy Das <nirmoy.das@amd.com>
      Cc: Deepak R Varma <mh12gx2825@gmail.com>
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Kevin Wang <kevin1.wang@amd.com>
      Cc: Chen Li <chenli@uniontech.com>
      Cc: Luben Tuikov <luben.tuikov@amd.com>
      Cc: "Marek Olšák" <marek.olsak@amd.com>
      Cc: Dennis Li <Dennis.Li@amd.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
      Cc: Sonny Jiang <sonny.jiang@amd.com>
      Cc: Boris Brezillon <boris.brezillon@collabora.com>
      Cc: Tian Tao <tiantao6@hisilicon.com>
      Cc: etnaviv@lists.freedesktop.org
      Cc: lima@lists.freedesktop.org
      Cc: linux-media@vger.kernel.org
      Cc: linaro-mm-sig@lists.linaro.org
      Cc: Emma Anholt <emma@anholt.net>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Sean Paul <sean@poorly.run>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20210817084917.3555822-1-daniel.vetter@ffwll.ch
      dbe48d03
  24. 03 8月, 2021 1 次提交
  25. 29 7月, 2021 1 次提交
  26. 13 7月, 2021 1 次提交