Skip to content
Snippets Groups Projects
  1. Mar 18, 2025
  2. Mar 14, 2025
  3. Mar 12, 2025
  4. Mar 04, 2025
  5. Feb 21, 2025
  6. Feb 19, 2025
  7. Feb 18, 2025
    • SRINIVASAN SHANMUGAM's avatar
      drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid... · 708a65f0
      SRINIVASAN SHANMUGAM authored
      drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV
      
      RLCG Register Access is a way for virtual functions to safely access GPU
      registers in a virtualized environment., including TLB flushes and
      register reads. When multiple threads or VFs try to access the same
      registers simultaneously, it can lead to race conditions. By using the
      RLCG interface, the driver can serialize access to the registers. This
      means that only one thread can access the registers at a time,
      preventing conflicts and ensuring that operations are performed
      correctly. Additionally, when a low-priority task holds a mutex that a
      high-priority task needs, ie., If a thread holding a spinlock tries to
      acquire a mutex, it can lead to priority inversion. register access in
      amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical.
      
      The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being
      called, which attempts to acquire the mutex. This function is invoked
      from amdgpu_sriov_wreg, which in turn is called from
      gmc_v11_0_flush_gpu_tlb.
      
      The [ BUG: Invalid wait context ] indicates that a thread is trying to
      acquire a mutex while it is in a context that does not allow it to sleep
      (like holding a spinlock).
      
      Fixes the below:
      
      [  253.013423] =============================
      [  253.013434] [ BUG: Invalid wait context ]
      [  253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G     U     OE
      [  253.013464] -----------------------------
      [  253.013475] kworker/0:1/10 is trying to lock:
      [  253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
      [  253.013815] other info that might help us debug this:
      [  253.013827] context-{4:4}
      [  253.013835] 3 locks held by kworker/0:1/10:
      [  253.013847]  #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680
      [  253.013877]  #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680
      [  253.013905]  #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu]
      [  253.014154] stack backtrace:
      [  253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G     U     OE      6.12.0-amdstaging-drm-next-lol-050225 #14
      [  253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
      [  253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024
      [  253.014224] Workqueue: events work_for_cpu_fn
      [  253.014241] Call Trace:
      [  253.014250]  <TASK>
      [  253.014260]  dump_stack_lvl+0x9b/0xf0
      [  253.014275]  dump_stack+0x10/0x20
      [  253.014287]  __lock_acquire+0xa47/0x2810
      [  253.014303]  ? srso_alias_return_thunk+0x5/0xfbef5
      [  253.014321]  lock_acquire+0xd1/0x300
      [  253.014333]  ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
      [  253.014562]  ? __lock_acquire+0xa6b/0x2810
      [  253.014578]  __mutex_lock+0x85/0xe20
      [  253.014591]  ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
      [  253.014782]  ? sched_clock_noinstr+0x9/0x10
      [  253.014795]  ? srso_alias_return_thunk+0x5/0xfbef5
      [  253.014808]  ? local_clock_noinstr+0xe/0xc0
      [  253.014822]  ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
      [  253.015012]  ? srso_alias_return_thunk+0x5/0xfbef5
      [  253.015029]  mutex_lock_nested+0x1b/0x30
      [  253.015044]  ? mutex_lock_nested+0x1b/0x30
      [  253.015057]  amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
      [  253.015249]  amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu]
      [  253.015435]  gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu]
      [  253.015667]  gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu]
      [  253.015901]  ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu]
      [  253.016159]  ? srso_alias_return_thunk+0x5/0xfbef5
      [  253.016173]  ? smu_hw_init+0x18d/0x300 [amdgpu]
      [  253.016403]  amdgpu_device_init+0x29ad/0x36a0 [amdgpu]
      [  253.016614]  amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu]
      [  253.017057]  amdgpu_pci_probe+0x1c2/0x660 [amdgpu]
      [  253.017493]  local_pci_probe+0x4b/0xb0
      [  253.017746]  work_for_cpu_fn+0x1a/0x30
      [  253.017995]  process_one_work+0x21e/0x680
      [  253.018248]  worker_thread+0x190/0x330
      [  253.018500]  ? __pfx_worker_thread+0x10/0x10
      [  253.018746]  kthread+0xe7/0x120
      [  253.018988]  ? __pfx_kthread+0x10/0x10
      [  253.019231]  ret_from_fork+0x3c/0x60
      [  253.019468]  ? __pfx_kthread+0x10/0x10
      [  253.019701]  ret_from_fork_asm+0x1a/0x30
      [  253.019939]  </TASK>
      
      v2: s/spin_trylock/spin_lock_irqsave to be safe (Christian).
      
      Fixes: e864180e ("drm/amdgpu: Add lock around VF RLCG interface")
      Cc: lin cao <lin.cao@amd.com>
      Cc: Jingwen Chen <Jingwen.Chen2@amd.com>
      Cc: Victor Skvortsov <victor.skvortsov@amd.com>
      Cc: Zhigang Luo <zhigang.luo@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSrinivasan Shanmugam <srinivasan.shanmugam@amd.com>
      Suggested-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      708a65f0
  8. Feb 17, 2025
  9. Feb 14, 2025
  10. Feb 07, 2025
  11. Jan 20, 2025
    • SRINIVASAN SHANMUGAM's avatar
      drm/amd/amdgpu: Prevent null pointer dereference in GPU bandwidth calculation · afddc2d2
      SRINIVASAN SHANMUGAM authored
      
      If the parent is NULL, adev->pdev is used to retrieve the PCIe speed and
      width, ensuring that  the function can still determine these
      capabilities from the device itself.
      
      Fixes the below:
      drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:6193 amdgpu_device_gpu_bandwidth()
      	error: we previously assumed 'parent' could be null (see line 6180)
      
      drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
          6170 static void amdgpu_device_gpu_bandwidth(struct amdgpu_device *adev,
          6171                                         enum pci_bus_speed *speed,
          6172                                         enum pcie_link_width *width)
          6173 {
          6174         struct pci_dev *parent = adev->pdev;
          6175
          6176         if (!speed || !width)
          6177                 return;
          6178
          6179         parent = pci_upstream_bridge(parent);
          6180         if (parent && parent->vendor == PCI_VENDOR_ID_ATI) {
                           ^^^^^^
      If parent is NULL
      
          6181                 /* use the upstream/downstream switches internal to dGPU */
          6182                 *speed = pcie_get_speed_cap(parent);
          6183                 *width = pcie_get_width_cap(parent);
          6184                 while ((parent = pci_upstream_bridge(parent))) {
          6185                         if (parent->vendor == PCI_VENDOR_ID_ATI) {
          6186                                 /* use the upstream/downstream switches internal to dGPU */
          6187                                 *speed = pcie_get_speed_cap(parent);
          6188                                 *width = pcie_get_width_cap(parent);
          6189                         }
          6190                 }
          6191         } else {
          6192                 /* use the device itself */
      --> 6193                 *speed = pcie_get_speed_cap(parent);
                                                           ^^^^^^ Then we are toasted here.
      
          6194                 *width = pcie_get_width_cap(parent);
          6195         }
          6196 }
      
      Fixes: 9e424a5d ("drm/amdgpu: cache gpu pcie link width")
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@linaro.org>
      Signed-off-by: default avatarSrinivasan Shanmugam <srinivasan.shanmugam@amd.com>
      Suggested-by: default avatarLijo Lazar <lijo.lazar@amd.com>
      Reviewed-by: default avatarLijo Lazar <lijo.lazar@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      afddc2d2
  12. Jan 16, 2025
  13. Jan 13, 2025
  14. Dec 12, 2024
  15. Dec 11, 2024
  16. Dec 10, 2024
  17. Dec 05, 2024
  18. Dec 02, 2024
  19. Nov 21, 2024
    • Alex Deucher's avatar
      drm/amdgpu: partially revert VCN IP block instancing support · fba4761c
      Alex Deucher authored
      
      This partially reverts the VCN IP block rework.  There
      are too many corner cases and chances for regressions.
      
      While this aligned better with the original design, years
      of hardware has used the old pattern.  Best to stick with
      it at this point.
      
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      fba4761c
    • lijo lazar's avatar
      drm/amdgpu: Prefer RAS recovery for scheduler hang · 186d1f4d
      lijo lazar authored
      
      Before scheduling a recovery due to scheduler/job hang, check if a RAS
      error is detected. If so, choose RAS recovery to handle the situation. A
      scheduler/job hang could be the side effect of a RAS error. In such
      cases, it is required to go through the RAS error recovery process. A
      RAS error recovery process in certains cases also could avoid a full
      device device reset.
      
      An error state is maintained in RAS context to detect the block
      affected. Fatal Error state uses unused block id. Set the block id when
      error is detected. If the interrupt handler detected a poison error,
      it's not required to look for a fatal error. Skip fatal error checking
      in such cases.
      
      Signed-off-by: default avatarLijo Lazar <lijo.lazar@amd.com>
      Reviewed-by: default avatarHawking Zhang <Hawking.Zhang@amd.com>
      186d1f4d
    • Vitaly Prosyak's avatar
      drm/amdgpu: fix usage slab after free · 37fb0213
      Vitaly Prosyak authored
      
      [  +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
      [  +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147
      
      [  +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1
      [  +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
      [  +0.000016] Call Trace:
      [  +0.000008]  <TASK>
      [  +0.000009]  dump_stack_lvl+0x76/0xa0
      [  +0.000017]  print_report+0xce/0x5f0
      [  +0.000017]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
      [  +0.000019]  ? srso_return_thunk+0x5/0x5f
      [  +0.000015]  ? kasan_complete_mode_report_info+0x72/0x200
      [  +0.000016]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
      [  +0.000019]  kasan_report+0xbe/0x110
      [  +0.000015]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
      [  +0.000023]  __asan_report_load8_noabort+0x14/0x30
      [  +0.000014]  drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
      [  +0.000020]  ? srso_return_thunk+0x5/0x5f
      [  +0.000013]  ? __kasan_check_write+0x14/0x30
      [  +0.000016]  ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]
      [  +0.000020]  ? srso_return_thunk+0x5/0x5f
      [  +0.000013]  ? __kasan_check_write+0x14/0x30
      [  +0.000013]  ? srso_return_thunk+0x5/0x5f
      [  +0.000013]  ? enable_work+0x124/0x220
      [  +0.000015]  ? __pfx_enable_work+0x10/0x10
      [  +0.000013]  ? srso_return_thunk+0x5/0x5f
      [  +0.000014]  ? free_large_kmalloc+0x85/0xf0
      [  +0.000016]  drm_sched_entity_destroy+0x18/0x30 [gpu_sched]
      [  +0.000020]  amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]
      [  +0.000735]  ? __kasan_check_read+0x11/0x20
      [  +0.000016]  vce_v4_0_sw_fini+0x80/0x110 [amdgpu]
      [  +0.000726]  amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]
      [  +0.000679]  ? mutex_unlock+0x80/0xe0
      [  +0.000017]  ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]
      [  +0.000662]  ? srso_return_thunk+0x5/0x5f
      [  +0.000014]  ? __kasan_check_write+0x14/0x30
      [  +0.000013]  ? srso_return_thunk+0x5/0x5f
      [  +0.000013]  ? mutex_unlock+0x80/0xe0
      [  +0.000016]  amdgpu_driver_release_kms+0x16/0x80 [amdgpu]
      [  +0.000663]  drm_minor_release+0xc9/0x140 [drm]
      [  +0.000081]  drm_release+0x1fd/0x390 [drm]
      [  +0.000082]  __fput+0x36c/0xad0
      [  +0.000018]  __fput_sync+0x3c/0x50
      [  +0.000014]  __x64_sys_close+0x7d/0xe0
      [  +0.000014]  x64_sys_call+0x1bc6/0x2680
      [  +0.000014]  do_syscall_64+0x70/0x130
      [  +0.000014]  ? srso_return_thunk+0x5/0x5f
      [  +0.000014]  ? irqentry_exit_to_user_mode+0x60/0x190
      [  +0.000015]  ? srso_return_thunk+0x5/0x5f
      [  +0.000014]  ? irqentry_exit+0x43/0x50
      [  +0.000012]  ? srso_return_thunk+0x5/0x5f
      [  +0.000013]  ? exc_page_fault+0x7c/0x110
      [  +0.000015]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
      [  +0.000014] RIP: 0033:0x7ffff7b14f67
      [  +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff
      [  +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
      [  +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67
      [  +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003
      [  +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000
      [  +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8
      [  +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040
      [  +0.000020]  </TASK>
      
      [  +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:
      [  +0.000014]  kasan_save_stack+0x28/0x60
      [  +0.000008]  kasan_save_track+0x18/0x70
      [  +0.000007]  kasan_save_alloc_info+0x38/0x60
      [  +0.000007]  __kasan_kmalloc+0xc1/0xd0
      [  +0.000007]  kmalloc_trace_noprof+0x180/0x380
      [  +0.000007]  drm_sched_init+0x411/0xec0 [gpu_sched]
      [  +0.000012]  amdgpu_device_init+0x695f/0xa610 [amdgpu]
      [  +0.000658]  amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]
      [  +0.000662]  amdgpu_pci_probe+0x361/0xf30 [amdgpu]
      [  +0.000651]  local_pci_probe+0xe7/0x1b0
      [  +0.000009]  pci_device_probe+0x248/0x890
      [  +0.000008]  really_probe+0x1fd/0x950
      [  +0.000008]  __driver_probe_device+0x307/0x410
      [  +0.000007]  driver_probe_device+0x4e/0x150
      [  +0.000007]  __driver_attach+0x223/0x510
      [  +0.000006]  bus_for_each_dev+0x102/0x1a0
      [  +0.000007]  driver_attach+0x3d/0x60
      [  +0.000006]  bus_add_driver+0x2ac/0x5f0
      [  +0.000006]  driver_register+0x13d/0x490
      [  +0.000008]  __pci_register_driver+0x1ee/0x2b0
      [  +0.000007]  llc_sap_close+0xb0/0x160 [llc]
      [  +0.000009]  do_one_initcall+0x9c/0x3e0
      [  +0.000008]  do_init_module+0x241/0x760
      [  +0.000008]  load_module+0x51ac/0x6c30
      [  +0.000006]  __do_sys_init_module+0x234/0x270
      [  +0.000007]  __x64_sys_init_module+0x73/0xc0
      [  +0.000006]  x64_sys_call+0xe3/0x2680
      [  +0.000006]  do_syscall_64+0x70/0x130
      [  +0.000007]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
      
      [  +0.000015] Freed by task 2147 on cpu 6 at 160.507651s:
      [  +0.000013]  kasan_save_stack+0x28/0x60
      [  +0.000007]  kasan_save_track+0x18/0x70
      [  +0.000007]  kasan_save_free_info+0x3b/0x60
      [  +0.000007]  poison_slab_object+0x115/0x1c0
      [  +0.000007]  __kasan_slab_free+0x34/0x60
      [  +0.000007]  kfree+0xfa/0x2f0
      [  +0.000007]  drm_sched_fini+0x19d/0x410 [gpu_sched]
      [  +0.000012]  amdgpu_fence_driver_sw_fini+0xc4/0x2f0 [amdgpu]
      [  +0.000662]  amdgpu_device_fini_sw+0x77/0xfc0 [amdgpu]
      [  +0.000653]  amdgpu_driver_release_kms+0x16/0x80 [amdgpu]
      [  +0.000655]  drm_minor_release+0xc9/0x140 [drm]
      [  +0.000071]  drm_release+0x1fd/0x390 [drm]
      [  +0.000071]  __fput+0x36c/0xad0
      [  +0.000008]  __fput_sync+0x3c/0x50
      [  +0.000007]  __x64_sys_close+0x7d/0xe0
      [  +0.000007]  x64_sys_call+0x1bc6/0x2680
      [  +0.000007]  do_syscall_64+0x70/0x130
      [  +0.000007]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
      
      [  +0.000014] The buggy address belongs to the object at ffff8881b8605f80
                     which belongs to the cache kmalloc-64 of size 64
      [  +0.000020] The buggy address is located 8 bytes inside of
                     freed 64-byte region [ffff8881b8605f80, ffff8881b8605fc0)
      
      [  +0.000028] The buggy address belongs to the physical page:
      [  +0.000011] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1b8605
      [  +0.000008] anon flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
      [  +0.000007] page_type: 0xffffefff(slab)
      [  +0.000009] raw: 0017ffffc0000000 ffff8881000428c0 0000000000000000 dead000000000001
      [  +0.000006] raw: 0000000000000000 0000000000200020 00000001ffffefff 0000000000000000
      [  +0.000006] page dumped because: kasan: bad access detected
      
      [  +0.000012] Memory state around the buggy address:
      [  +0.000011]  ffff8881b8605e80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [  +0.000015]  ffff8881b8605f00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      [  +0.000015] >ffff8881b8605f80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [  +0.000013]                       ^
      [  +0.000011]  ffff8881b8606000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc
      [  +0.000014]  ffff8881b8606080: fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb fb
      [  +0.000013] ==================================================================
      
      The issue reproduced on VG20 during the IGT pci_unplug test.
      The root cause of the issue is that the function drm_sched_fini is called before drm_sched_entity_kill.
      In drm_sched_fini, the drm_sched_rq structure is freed, but this structure is later accessed by
      each entity within the run queue, leading to invalid memory access.
      To resolve this, the order of cleanup calls is updated:
      
          Before:
              amdgpu_fence_driver_sw_fini
              amdgpu_device_ip_fini
      
          After:
              amdgpu_device_ip_fini
              amdgpu_fence_driver_sw_fini
      
      This updated order ensures that all entities in the IPs are cleaned up first, followed by proper
      cleanup of the schedulers.
      
      Additional Investigation:
      
      During debugging, another issue was identified in the amdgpu_vce_sw_fini function. The vce.vcpu_bo
      buffer must be freed only as the final step in the cleanup process to prevent any premature
      access during earlier cleanup stages.
      
      v2: Using Christian suggestion call drm_sched_entity_destroy before drm_sched_fini.
      
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarVitaly Prosyak <vitaly.prosyak@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      37fb0213
  20. Nov 20, 2024
  21. Nov 11, 2024
Loading