Hi Arun,
Am 25.11.24 um 07:40 schrieb Paneer Selvam, Arunpravin:
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?
No, that is clearly a bug inside the kernel code.
The question is when and why does the kernel code add NULL into the
fences array? That should never happen in the first place.
Regards,
Christian.
Thanks,
Arun.
Regards,
Christian.
+
userq_fence = to_amdgpu_userq_fence(fences[i]);
if (!userq_fence) {
/*
