linux-kernel - [RFC PATCH 39/60] hyper_dmabuf: correcting DMA-BUF clean-up order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1513711816-2618-39-git-send-email-dongwon.kim@intel.com>
Date:   Tue, 19 Dec 2017 11:29:55 -0800
From:   Dongwon Kim <dongwon.kim@...el.com>
To:     linux-kernel@...r.kernel.org
Cc:     dri-devel@...ts.freedesktop.org, xen-devel@...ts.xenproject.org,
        mateuszx.potrola@...el.com, dongwon.kim@...el.com
Subject: [RFC PATCH 39/60] hyper_dmabuf: correcting DMA-BUF clean-up order

Reordering clean-up procedure

Signed-off-by: Dongwon Kim <dongwon.kim@...el.com>
---
 drivers/xen/hyper_dmabuf/hyper_dmabuf_ioctl.c | 37 +++++++++++++++++----------
 1 file changed, 24 insertions(+), 13 deletions(-)

diff --git a/drivers/xen/hyper_dmabuf/hyper_dmabuf_ioctl.c b/drivers/xen/hyper_dmabuf/hyper_dmabuf_ioctl.c
index b77b156..2ff2c145 100644
--- a/drivers/xen/hyper_dmabuf/hyper_dmabuf_ioctl.c
+++ b/drivers/xen/hyper_dmabuf/hyper_dmabuf_ioctl.c
@@ -148,21 +148,24 @@ static int hyper_dmabuf_export_remote_ioctl(struct file *filp, void *data)
 	attachment = dma_buf_attach(dma_buf, hyper_dmabuf_private.device);
 	if (IS_ERR(attachment)) {
 		dev_err(hyper_dmabuf_private.device, "Cannot get attachment\n");
-		return PTR_ERR(attachment);
+		ret = PTR_ERR(attachment);
+		goto fail_attach;
 	}
 
 	sgt = dma_buf_map_attachment(attachment, DMA_BIDIRECTIONAL);
 
 	if (IS_ERR(sgt)) {
 		dev_err(hyper_dmabuf_private.device, "Cannot map attachment\n");
-		return PTR_ERR(sgt);
+		ret = PTR_ERR(sgt);
+		goto fail_map_attachment;
 	}
 
 	sgt_info = kcalloc(1, sizeof(*sgt_info), GFP_KERNEL);
 
 	if(!sgt_info) {
 		dev_err(hyper_dmabuf_private.device, "no more space left\n");
-		return -ENOMEM;
+		ret = -ENOMEM;
+		goto fail_sgt_info_creation;
 	}
 
 	sgt_info->hid = hyper_dmabuf_get_hid();
@@ -171,8 +174,8 @@ static int hyper_dmabuf_export_remote_ioctl(struct file *filp, void *data)
 	if(sgt_info->hid.id == -1) {
 		dev_err(hyper_dmabuf_private.device,
 			"exceeds allowed number of dmabuf to be exported\n");
-		/* TODO: Cleanup sgt */
-		return -ENOMEM;
+		ret = -ENOMEM;
+		goto fail_sgt_info_creation;
 	}
 
 	/* TODO: We might need to consider using port number on event channel? */
@@ -286,6 +289,8 @@ static int hyper_dmabuf_export_remote_ioctl(struct file *filp, void *data)
 
 	return ret;
 
+/* Clean-up if error occurs */
+
 fail_send_request:
 	kfree(req);
 
@@ -293,20 +298,26 @@ static int hyper_dmabuf_export_remote_ioctl(struct file *filp, void *data)
 	hyper_dmabuf_remove_exported(sgt_info->hid);
 
 fail_export:
-	dma_buf_unmap_attachment(sgt_info->active_attached->attach,
-				 sgt_info->active_sgts->sgt,
-				 DMA_BIDIRECTIONAL);
-	dma_buf_detach(sgt_info->dma_buf, sgt_info->active_attached->attach);
-	dma_buf_put(sgt_info->dma_buf);
-
 	kfree(sgt_info->va_vmapped);
+
 fail_map_va_vmapped:
 	kfree(sgt_info->va_kmapped);
+
 fail_map_va_kmapped:
-	kfree(sgt_info->active_sgts);
-fail_map_active_sgts:
 	kfree(sgt_info->active_attached);
+
 fail_map_active_attached:
+	kfree(sgt_info->active_sgts);
+
+fail_map_active_sgts:
+fail_sgt_info_creation:
+	dma_buf_unmap_attachment(attachment, sgt, DMA_BIDIRECTIONAL);
+
+fail_map_attachment:
+	dma_buf_detach(dma_buf, attachment);
+
+fail_attach:
+	dma_buf_put(dma_buf);
 
 	return ret;
 }
-- 
2.7.4