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