[PATCH] selftests/net: missing close function in randomize function

Liu Jing posted 1 patch 1 year, 7 months ago
tools/testing/selftests/net/tcp_mmap.c | 1 +
1 file changed, 1 insertion(+)
[PATCH] selftests/net: missing close function in randomize function
Posted by Liu Jing 1 year, 7 months ago
in randomize function, there is a open function, but there is no
close function in the randomize, which is easy to cause memory leaks.

Signed-off-by: Liu Jing <liujing@cmss.chinamobile.com>
---
 tools/testing/selftests/net/tcp_mmap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/net/tcp_mmap.c b/tools/testing/selftests/net/tcp_mmap.c
index 4fcce5150850..ab305e262d0a 100644
--- a/tools/testing/selftests/net/tcp_mmap.c
+++ b/tools/testing/selftests/net/tcp_mmap.c
@@ -438,6 +438,7 @@ static void randomize(void *target, size_t count)
 		perror("read /dev/urandom");
 		exit(1);
 	}
+	close(urandom);
 }
 
 int main(int argc, char *argv[])
-- 
2.33.0
Re: [PATCH] selftests/net: missing close function in randomize function
Posted by Paolo Abeni 1 year, 7 months ago
On Fri, 2024-07-05 at 16:24 +0800, Liu Jing wrote:
> in randomize function, there is a open function, but there is no
> close function in the randomize, which is easy to cause memory leaks.

Please not that the file descriptor is not leaked, the kernel will
dispose it at process exit() time.

> 
> Signed-off-by: Liu Jing <liujing@cmss.chinamobile.com>
> ---
>  tools/testing/selftests/net/tcp_mmap.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/testing/selftests/net/tcp_mmap.c b/tools/testing/selftests/net/tcp_mmap.c
> index 4fcce5150850..ab305e262d0a 100644
> --- a/tools/testing/selftests/net/tcp_mmap.c
> +++ b/tools/testing/selftests/net/tcp_mmap.c
> @@ -438,6 +438,7 @@ static void randomize(void *target, size_t count)
>  		perror("read /dev/urandom");
>  		exit(1);
>  	}
> +	close(urandom);
>  }
>  
>  int main(int argc, char *argv[])

This is outside any loop, so the overall effect WRT the self-test
itself is not visible.

I think we are better off without this kind of changes, unless they are
part of a largish re-factor.

Thanks,

Paolo