Hi Christian,
On 11/20/2024 4:04 PM, Christian König wrote:
Am 20.11.24 um 10:26 schrieb Arunpravin Paneer Selvam:
We are observing a NULL value in the non userq fences,
thus added a NULL pointer check just to avoid the
NULL pointer dereference crash.
v2: Moved the NULL check above the non userq check.
Signed-off-by: Arunpravin Paneer Selvam
<Arunpravin.PaneerSelvam@xxxxxxx>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
index 6157a540c929..76f7babd7a54 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
@@ -815,6 +815,9 @@ int amdgpu_userq_wait_ioctl(struct drm_device
*dev, void *data,
struct amdgpu_userq_fence *userq_fence;
u32 index;
+ if (!fences[i])
+ continue;
That should never ever happen in the first place.
All fences in the array either come from some reservation object or
drm_syncobj. If any of those are NULL then there is a bug somewhere else.
We are observing the NULL fence for the non user queue fences, and these
GEM BO reservation objects are coming userspace, should we request
mesa team to analyze this issue from userspace?
Thanks,
Arun.
Regards,
Christian.
+
userq_fence = to_amdgpu_userq_fence(fences[i]);
if (!userq_fence) {
/*
