[PATCH 1/3] drm/amdgpu: Add NULL ptr check for non userq fences

[Christian König]

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 at amd.com>
>>> ---
>>>   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) {
>>>                   /*
>