2023-11-24 09:27:20

by zhaimingbing

[permalink] [raw]
Subject: [PATCH] perf lock: Fix a memory leak on an error path

if a strdup-ed string is NULL,the allocated memory needs freeing.

Signed-off-by: zhaimingbing <[email protected]>
---
tools/perf/builtin-lock.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index b141f2134..086041bcb 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -2228,8 +2228,10 @@ static int __cmd_record(int argc, const char **argv)
else
ev_name = strdup(contention_tracepoints[j].name);

- if (!ev_name)
+ if (!ev_name) {
+ free(rec_argv);
return -ENOMEM;
+ }

rec_argv[i++] = "-e";
rec_argv[i++] = ev_name;
--
2.33.0




2023-11-24 09:56:06

by Peter Zijlstra

[permalink] [raw]
Subject: Re: [PATCH] perf lock: Fix a memory leak on an error path

On Fri, Nov 24, 2023 at 05:26:57PM +0800, zhaimingbing wrote:
> if a strdup-ed string is NULL,the allocated memory needs freeing.
>
> Signed-off-by: zhaimingbing <[email protected]>
> ---
> tools/perf/builtin-lock.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
> index b141f2134..086041bcb 100644
> --- a/tools/perf/builtin-lock.c
> +++ b/tools/perf/builtin-lock.c
> @@ -2228,8 +2228,10 @@ static int __cmd_record(int argc, const char **argv)
> else
> ev_name = strdup(contention_tracepoints[j].name);
>
> - if (!ev_name)
> + if (!ev_name) {
> + free(rec_argv);
> return -ENOMEM;
> + }

Isn't this an error path straight into exit?

2023-11-24 12:57:20

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] perf lock: Fix a memory leak on an error path


* Peter Zijlstra <[email protected]> wrote:

> On Fri, Nov 24, 2023 at 05:26:57PM +0800, zhaimingbing wrote:
> > if a strdup-ed string is NULL,the allocated memory needs freeing.
> >
> > Signed-off-by: zhaimingbing <[email protected]>
> > ---
> > tools/perf/builtin-lock.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
> > index b141f2134..086041bcb 100644
> > --- a/tools/perf/builtin-lock.c
> > +++ b/tools/perf/builtin-lock.c
> > @@ -2228,8 +2228,10 @@ static int __cmd_record(int argc, const char **argv)
> > else
> > ev_name = strdup(contention_tracepoints[j].name);
> >
> > - if (!ev_name)
> > + if (!ev_name) {
> > + free(rec_argv);
> > return -ENOMEM;
> > + }
>
> Isn't this an error path straight into exit?

It increases the quality of implementation if resources are free()d
consistently regardless of whether the task is going to exit() immediately,
for example it makes it easier to validate perf for the lack of memory
leaks with Valgrind.

Thanks,

Ingo

2023-11-27 13:18:16

by Arnaldo Carvalho de Melo

[permalink] [raw]
Subject: Re: [PATCH] perf lock: Fix a memory leak on an error path

Em Fri, Nov 24, 2023 at 01:56:35PM +0100, Ingo Molnar escreveu:
>
> * Peter Zijlstra <[email protected]> wrote:
>
> > On Fri, Nov 24, 2023 at 05:26:57PM +0800, zhaimingbing wrote:
> > > if a strdup-ed string is NULL,the allocated memory needs freeing.
> > >
> > > Signed-off-by: zhaimingbing <[email protected]>
> > > ---
> > > tools/perf/builtin-lock.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
> > > index b141f2134..086041bcb 100644
> > > --- a/tools/perf/builtin-lock.c
> > > +++ b/tools/perf/builtin-lock.c
> > > @@ -2228,8 +2228,10 @@ static int __cmd_record(int argc, const char **argv)
> > > else
> > > ev_name = strdup(contention_tracepoints[j].name);
> > >
> > > - if (!ev_name)
> > > + if (!ev_name) {
> > > + free(rec_argv);
> > > return -ENOMEM;
> > > + }
> >
> > Isn't this an error path straight into exit?
>
> It increases the quality of implementation if resources are free()d
> consistently regardless of whether the task is going to exit() immediately,
> for example it makes it easier to validate perf for the lack of memory
> leaks with Valgrind.

I'm taking this positive comment about the patch as an Acked-by, ok?

- Arnaldo