DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] there are some memory leak about Dir operator
@ 2014-08-19  3:39 zhang.zhangkun
  2014-08-19  3:53 ` Zhang, Helin
  0 siblings, 1 reply; 5+ messages in thread
From: zhang.zhangkun @ 2014-08-19  3:39 UTC (permalink / raw)
  To: dev; +Cc: 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] [PATCH] there are some memory leak about Dir operator
  2014-08-19  3:39 [dpdk-dev] [PATCH] there are some memory leak about Dir operator zhang.zhangkun
@ 2014-08-19  3:53 ` Zhang, Helin
  2014-08-19  6:10   ` [dpdk-dev] 答复: " Zhangkun (K)
  0 siblings, 1 reply; 5+ messages in thread
From: Zhang, Helin @ 2014-08-19  3:53 UTC (permalink / raw)
  To: zhang.zhangkun, dev; +Cc: zhangkun



> -----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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [dpdk-dev] 答复:  [PATCH] there are some memory leak about Dir operator
  2014-08-19  3:53 ` Zhang, Helin
@ 2014-08-19  6:10   ` Zhangkun (K)
  0 siblings, 0 replies; 5+ messages in thread
From: Zhangkun (K) @ 2014-08-19  6:10 UTC (permalink / raw)
  To: Zhang, Helin, dev

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] [PATCH] there are some memory leak about Dir operator
  2014-08-19  3:51 [dpdk-dev] " zhang.zhangkun
@ 2014-08-29 10:43 ` Thomas Monjalon
  0 siblings, 0 replies; 5+ messages in thread
From: Thomas Monjalon @ 2014-08-29 10:43 UTC (permalink / raw)
  To: zhang.zhangkun; +Cc: dev

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [dpdk-dev] [PATCH] there are some memory leak about Dir operator
@ 2014-08-19  3:51 zhang.zhangkun
  2014-08-29 10:43 ` Thomas Monjalon
  0 siblings, 1 reply; 5+ messages in thread
From: zhang.zhangkun @ 2014-08-19  3:51 UTC (permalink / raw)
  To: dev; +Cc: 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-08-29 10:39 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-19  3:39 [dpdk-dev] [PATCH] there are some memory leak about Dir operator zhang.zhangkun
2014-08-19  3:53 ` Zhang, Helin
2014-08-19  6:10   ` [dpdk-dev] 答复: " Zhangkun (K)
2014-08-19  3:51 [dpdk-dev] " zhang.zhangkun
2014-08-29 10:43 ` Thomas Monjalon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).