[dpdk-dev] [PATCH] there are some memory leak about Dir operator

[dpdk-dev] [PATCH] there are some memory leak about Dir operator

[zhang.zhangkun]

From: zhangkun <zhangk.zhangkun@huawei.com>


Signed-off-by: zhangkun <zhangk.zhangkun@huawei.com>
---
 lib/librte_eal/linuxapp/eal/eal_hugepage_info.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
index b72a205..d784b7c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
+++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
@@ -311,12 +311,14 @@ eal_hugepage_info_init(void)
 				/* if blocking lock failed */
 				if (flock(hpi->lock_descriptor, LOCK_EX) == -1) {
 					RTE_LOG(CRIT, EAL, "Failed to lock hugepage directory!\n");
+					closedir(dir);
 					return -1;
 				}
 				/* clear out the hugepages dir from unused pages */
-				if (clear_hugedir(hpi->hugedir) == -1)
+				if (clear_hugedir(hpi->hugedir) == -1) {
+					closedir(dir);
 					return -1;
-
+				}
 				/* for now, put all pages into socket 0,
 				 * later they will be sorted */
 				hpi->num_pages[0] = get_num_hugepages(dirent->d_name);
-- 
1.7.3.1.msysgit.0

Re: [dpdk-dev] [PATCH] there are some memory leak about Dir operator

[Thomas Monjalon]

2014-08-19 11:51, zhang.zhangkun@huawei.com:
> From: zhangkun <zhangk.zhangkun@huawei.com>
> 
> 
> Signed-off-by: zhangkun <zhangk.zhangkun@huawei.com>

Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>

Log changed to:
  eal: fix memory leak in hugepage error cases
  The sysfs directory for hugepages parsing was not closed properly in some
  error cases.

Applied for version 1.7.1.

Thanks
-- 
Thomas

[dpdk-dev] 答复: [PATCH] there are some memory leak about Dir operator

[Zhangkun (K)]

Hi, Helin
This is no problem with the OS dealing with resource recovery during process exiting. However,I consider the following principles. 
  1.The function internally allocated memory is returned before releasing memory resources to prevent the caller did not release the cause memory leaks;
  2.The function should be obviously allocated and released memory. It is best not to recover from the os, otherwise relatively poor readability;
  3.In some scenarios the dpdk as part of the component is running in the background. The dpdk application happen error when try not to lead to the whole process of exit, only affects the part of the function fails;

----- Original Message -----
From: Zhang, Helin [mailto:helin.zhang@intel.com] 
Sent: Tuesday, August 19, 2014 11:53 AM
To: Zhangkun (K); dev@dpdk.org
Cc: zhangkun
Subject: RE: [dpdk-dev] [PATCH] there are some memory leak about Dir operator



> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of 
> zhang.zhangkun@huawei.com
> Sent: Tuesday, August 19, 2014 11:40 AM
> To: dev@dpdk.org
> Cc: zhangkun
> Subject: [dpdk-dev] [PATCH] there are some memory leak about Dir 
> operator
> 
> From: zhangkun <zhangk.zhangkun@huawei.com>
> 
> 
> Signed-off-by: zhangkun <zhangk.zhangkun@huawei.com>
> ---
>  lib/librte_eal/linuxapp/eal/eal_hugepage_info.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
> b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
> index b72a205..d784b7c 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
> @@ -311,12 +311,14 @@ eal_hugepage_info_init(void)
>  				/* if blocking lock failed */
>  				if (flock(hpi->lock_descriptor, LOCK_EX) == -1) {
>  					RTE_LOG(CRIT, EAL, "Failed to lock hugepage directory!\n");
> +					closedir(dir);
>  					return -1;
>  				}
>  				/* clear out the hugepages dir from unused pages */
> -				if (clear_hugedir(hpi->hugedir) == -1)
> +				if (clear_hugedir(hpi->hugedir) == -1) {
> +					closedir(dir);
>  					return -1;
> -
> +				}
>  				/* for now, put all pages into socket 0,
>  				 * later they will be sorted */
>  				hpi->num_pages[0] =
> get_num_hugepages(dirent->d_name);
> --
> 1.7.3.1.msysgit.0
> 

Hi Zhangkun

Could you help to explain more detailed about the memory leak? Wouldn't the OS take care of those closing during process exiting?

Regards,
Helin

Re: [dpdk-dev] [PATCH] there are some memory leak about Dir operator

[Zhang, Helin]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of
> zhang.zhangkun@huawei.com
> Sent: Tuesday, August 19, 2014 11:40 AM
> To: dev@dpdk.org
> Cc: zhangkun
> Subject: [dpdk-dev] [PATCH] there are some memory leak about Dir operator
> 
> From: zhangkun <zhangk.zhangkun@huawei.com>
> 
> 
> Signed-off-by: zhangkun <zhangk.zhangkun@huawei.com>
> ---
>  lib/librte_eal/linuxapp/eal/eal_hugepage_info.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
> b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
> index b72a205..d784b7c 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
> @@ -311,12 +311,14 @@ eal_hugepage_info_init(void)
>  				/* if blocking lock failed */
>  				if (flock(hpi->lock_descriptor, LOCK_EX) == -1) {
>  					RTE_LOG(CRIT, EAL, "Failed to lock hugepage
> directory!\n");
> +					closedir(dir);
>  					return -1;
>  				}
>  				/* clear out the hugepages dir from unused pages */
> -				if (clear_hugedir(hpi->hugedir) == -1)
> +				if (clear_hugedir(hpi->hugedir) == -1) {
> +					closedir(dir);
>  					return -1;
> -
> +				}
>  				/* for now, put all pages into socket 0,
>  				 * later they will be sorted */
>  				hpi->num_pages[0] =
> get_num_hugepages(dirent->d_name);
> --
> 1.7.3.1.msysgit.0
> 

Hi Zhangkun

Could you help to explain more detailed about the memory leak? Wouldn't the OS take care of those closing during process exiting?

Regards,
Helin

[dpdk-dev] [PATCH] there are some memory leak about Dir operator

[zhang.zhangkun]

From: zhangkun <zhangk.zhangkun@huawei.com>


Signed-off-by: zhangkun <zhangk.zhangkun@huawei.com>
---
 lib/librte_eal/linuxapp/eal/eal_hugepage_info.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
index b72a205..d784b7c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
+++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
@@ -311,12 +311,14 @@ eal_hugepage_info_init(void)
 				/* if blocking lock failed */
 				if (flock(hpi->lock_descriptor, LOCK_EX) == -1) {
 					RTE_LOG(CRIT, EAL, "Failed to lock hugepage directory!\n");
+					closedir(dir);
 					return -1;
 				}
 				/* clear out the hugepages dir from unused pages */
-				if (clear_hugedir(hpi->hugedir) == -1)
+				if (clear_hugedir(hpi->hugedir) == -1) {
+					closedir(dir);
 					return -1;
-
+				}
 				/* for now, put all pages into socket 0,
 				 * later they will be sorted */
 				hpi->num_pages[0] = get_num_hugepages(dirent->d_name);
-- 
1.7.3.1.msysgit.0