Backmerging to forward to v6.16-rc1 Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
This patch only affects 32bit systems. There are several integer
overflows bugs here but only the "sizeof(u32) * num_syncobj"
multiplication is a problem at runtime. (The last lines of this patch).
These variables are u32 variables that come from the user. The issue
is the multiplications can overflow leading to us allocating a smaller
buffer than intended. For the first couple integer overflows, the
syncobj_handles = memdup_user() allocation is immediately followed by
a kmalloc_array():
syncobj = kmalloc_array(num_syncobj_handles, sizeof(*syncobj), GFP_KERNEL);
In that situation the kmalloc_array() works as a bounds check and we
haven't accessed the syncobj_handlesp[] array yet so the integer overflow
is harmless.
But the "num_syncobj" multiplication doesn't have that and the integer
overflow could lead to an out of bounds access.
Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
With the goal of reducing the need for drivers to touch (and dereference) fence->ops, we move the 64-bit seqnos flag from struct dma_fence_ops to the fence->flags. Drivers which were setting this flag are changed to use new dma_fence_init64() instead of dma_fence_init(). v2: * Streamlined init and added kerneldoc. * Rebase for amdgpu userq which landed since. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> # v1 Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250515095004.28318-3-tvrtko.ursulin@igalia.com
Fix lockdep warnings.
[ +0.000637] ================================
[ +0.000004] WARNING: inconsistent lock state
[ +0.000004] 6.12.0+ #18 Tainted: G W OE
[ +0.000004] --------------------------------
[ +0.000004] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ +0.000004] Xwayland/1952 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ +0.000005] ffff8884636f4740 (&fence_drv->fence_list_lock){?...}-{2:2}, at: amdgpu_userq_fence_driver_destroy+0xb8/0x540 [amdgpu]
[ +0.000208] {IN-HARDIRQ-W} state was registered at:
[ +0.000004] lock_acquire.part.0+0x116/0x360
[ +0.000005] lock_acquire+0x7c/0xc0
[ +0.000005] _raw_spin_lock+0x2f/0x60
[ +0.000005] amdgpu_userq_fence_driver_process+0x75/0x400 [amdgpu]
[ +0.000185] gfx_v12_0_eop_irq+0x29f/0x420 [amdgpu]
[ +0.000210] amdgpu_irq_dispatch+0x2a4/0x7b0 [amdgpu]
[ +0.000191] amdgpu_ih_process+0x1e1/0x3d0 [amdgpu]
[ +0.000185] amdgpu_irq_handler+0x28/0xc0 [amdgpu]
[ +0.000183] __handle_irq_event_percpu+0x1bb/0x590
[ +0.000005] handle_irq_event+0xab/0x1d0
[ +0.000005] handle_edge_irq+0x1fd/0xc10
[ +0.000005] __common_interrupt+0x83/0x190
[ +0.000004] common_interrupt+0xb1/0xe0
[ +0.000005] asm_common_interrupt+0x27/0x40
[ +0.000004] cpuidle_enter_state+0x2ba/0x530
[ +0.000005] cpuidle_enter+0x4f/0xb0
[ +0.000006] call_cpuidle+0x46/0xd0
[ +0.000005] do_idle+0x367/0x430
[ +0.000004] cpu_startup_entry+0x58/0x70
[ +0.000005] start_secondary+0x224/0x2b0
[ +0.000005] common_startup_64+0x13e/0x141
[ +0.000005] irq event stamp: 88271
[ +0.000004] hardirqs last enabled at (88271): [<ffffffffad9ca7a1>] _raw_spin_unlock_irqrestore+0x51/0x80
[ +0.000005] hardirqs last disabled at (88270): [<ffffffffad9ca424>] _raw_spin_lock_irqsave+0x74/0x80
[ +0.000005] softirqs last enabled at (87858): [<ffffffffaa67377e>] __irq_exit_rcu+0x17e/0x1d0
[ +0.000005] softirqs last disabled at (87849): [<ffffffffaa67377e>] __irq_exit_rcu+0x17e/0x1d0
[ +0.000005]
other info that might help us debug this:
[ +0.000004] Possible unsafe locking scenario:
[ +0.000003] CPU0
[ +0.000004] ----
[ +0.000003] lock(&fence_drv->fence_list_lock);
v2:
Drop fence_list_flags and use xa_lock_irqsave() flags parameter (Christian)
Fix merge conflicts.
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To resolve the warning regarding the missing error code 'r' in amdgpu_userq_wait_ioctl(), assign the value 'r = -EINVAL'. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202505080458.rnV8YfiY-lkp@intel.com/ Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Arvind Yadav <Arvind.Yadav@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Keep only the latest fences to reduce the number of values
given back to userspace
v2: - Export this code from dma-fence-unwrap.c(by Christian).
v3: - To split this in a dma_buf patch and amd userq patch(by Sunil).
- No need to add a new function just re-use existing(by Christian).
v4: Export dma_fence_dedub_array function and used it(by Christian).
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Reviewed-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Arvind Yadav <Arvind.Yadav@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This error path should call amdgpu_bo_unreserve() before returning.
Fixes: d8675102ba32 ("drm/amdgpu: add vm root BO lock before accessing the vm")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
DRM_AMDGPU_NAVI3X_USERQ config support is not required for usermode queue. v2: rebase. Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Arvind Yadav <Arvind.Yadav@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
s/userqueue/userq/ 1. remove the mix of amdgpu_userqueue and amdgpu_userq 2. to be consistent with other amdgpu_userq_fence.c 3. it's shorter Reviewed-by: Prike Liang <Prike.Liang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add queue id support to the user queue wait IOCTL drm_amdgpu_userq_wait structure. This is required to retrieve the wait user queue and maintain the fence driver references in it so that the user queue in the same context releases their reference to the fence drivers at some point before queue destruction. Otherwise, we would gather those references until we don't have any more space left and crash. v2: Modify the UAPI comment as per the mesa and libdrm UAPI comment. Libdrm MR: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/408 Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34493 Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>