Re: [PATCH v2] drm/amdkfd: fix a memory leak in device_queue_manager_init()

[Felix Kuehling <felix.kuehling@amd.com>]

On 2026-01-06 04:30, Markus Elfring wrote:
> …
>> Move deallocate_hiq_sdma_mqd() up to ensure proper function
>> visibility at the point of use.
> …
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
>> @@ -2919,6 +2919,14 @@ static int allocate_hiq_sdma_mqd(struct device_queue_manager *dqm)
>>   	return retval;
>>   }
>>   
>> +static void deallocate_hiq_sdma_mqd(struct kfd_node *dev,
>> +				    struct kfd_mem_obj *mqd)
>> +{
>> +	WARN(!mqd, "No hiq sdma mqd trunk to free");
>> +
>> +	amdgpu_amdkfd_free_gtt_mem(dev->adev, &mqd->gtt_mem);
>> +}
> Is there also a need to reconsider the implementation of the applied
> null pointer check here?

Yeah, we have a WARN if mqd is NULL but then we still call 
amdgpu_amdkfd_free_gtt_mem. There is a NULL pointer check in 
amdgpu_amdkfd_free_gtt_mem, but &mqd->gtt_mem won't be NULL because it's 
not at the start of struct kfd_mem_obj. So you'd get a kernel oops if 
mqd is ever NULL here.

That said, I've never seen anyone complain about this WARN and a 
subsequent kernel oops.

The only other place that calls deallocate_hiq_sdma_mqd is 
device_queue_manager_uninit (only if not using MES). It can only be 
called with a valid dqm if device_queue_manager_init succeeded, which 
always ends with a valid dqm->hiq_sdma_mqd if not using MES.

My conclusion is that this WARN is just unnecessary. But it's also harmless.

Regards,
   Felix


>
> Regards,
> Markus