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
