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