blktests nvme 041,042 leak memory

Sagi Grimberg sagi at grimberg.me
Wed May 29 05:51:09 PDT 2024



On 29/05/2024 12:08, Maurizio Lombardi wrote:
> út 28. 5. 2024 v 11:44 odesílatel Maurizio Lombardi
> <mlombard at redhat.com> napsal:
>> This patch fixes the problem for TCP, it should also work for loop but
>> I've not tested it.
>>
>> http://bsdbackstore.eu/misc/0001-nvme-fix-memory-leak-when-nvme_init_ctrl-fails.patch
> I updated it to fix all the fabrics, with the exception of apple's driver
> because I am not sure I fully understand its probe process.

It'd be better if we didn't propagate this issue to the transport drivers.

Seems that the asymmetric part is the device_private allocated in device_add
but only removed in device_release (last reference).

A hack like this would also make the issue go away:
--
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index f62fd49c1411..8a9d51e1ccd6 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -4702,6 +4702,14 @@ int nvme_init_ctrl(struct nvme_ctrl *ctrl, struct 
device *dev,
         nvme_fault_inject_fini(&ctrl->fault_inject);
         dev_pm_qos_hide_latency_tolerance(ctrl->device);
         cdev_device_del(&ctrl->cdev, ctrl->device);
+       /*
+        * this is nasty hack, but device_add allocated a device private
+        * dev->p, which is freed assymmetricly in device_release, and
+        * in order to cleanup after ourselves, and not rely on the device
+        * .release handler (which also calls the nvme transport free 
handler)
+        * we explicitly free the device private.
+        */
+       kfree(ctrl->device->p);
  out_free_name:
         nvme_put_ctrl(ctrl);
         kfree_const(ctrl->device->kobj.name)
--

But this is ugly...



More information about the Linux-nvme mailing list