All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Rogers <irogers@google.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH] perf mem2node: avoid double free related to realloc
Date: Sat, 14 Mar 2020 09:49:37 -0700	[thread overview]
Message-ID: <CAP-5=fXZJidxHYeCqHcNPBArMe_aYwP0+u2dxiTD+V1fammK_Q@mail.gmail.com> (raw)
In-Reply-To: <20200314142332.GB492969@krava>

On Sat, Mar 14, 2020 at 7:23 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Fri, Mar 13, 2020 at 09:28:26PM -0700, Ian Rogers wrote:
> > Realloc of size zero is a free not an error, avoid this causing a double
> > free. Caught by clang's address sanitizer:
> >
> > ==2634==ERROR: AddressSanitizer: attempting double-free on 0x6020000015f0 in thread T0:
> >     #0 0x5649659297fd in free llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3
> >     #1 0x5649659e9251 in __zfree tools/lib/zalloc.c:13:2
> >     #2 0x564965c0f92c in mem2node__exit tools/perf/util/mem2node.c:114:2
> >     #3 0x564965a08b4c in perf_c2c__report tools/perf/builtin-c2c.c:2867:2
> >     #4 0x564965a0616a in cmd_c2c tools/perf/builtin-c2c.c:2989:10
> >     #5 0x564965944348 in run_builtin tools/perf/perf.c:312:11
> >     #6 0x564965943235 in handle_internal_command tools/perf/perf.c:364:8
> >     #7 0x5649659440c4 in run_argv tools/perf/perf.c:408:2
> >     #8 0x564965942e41 in main tools/perf/perf.c:538:3
> >
> > 0x6020000015f0 is located 0 bytes inside of 1-byte region [0x6020000015f0,0x6020000015f1)
> > freed by thread T0 here:
> >     #0 0x564965929da3 in realloc third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
> >     #1 0x564965c0f55e in mem2node__init tools/perf/util/mem2node.c:97:16
> >     #2 0x564965a08956 in perf_c2c__report tools/perf/builtin-c2c.c:2803:8
> >     #3 0x564965a0616a in cmd_c2c tools/perf/builtin-c2c.c:2989:10
> >     #4 0x564965944348 in run_builtin tools/perf/perf.c:312:11
> >     #5 0x564965943235 in handle_internal_command tools/perf/perf.c:364:8
> >     #6 0x5649659440c4 in run_argv tools/perf/perf.c:408:2
> >     #7 0x564965942e41 in main tools/perf/perf.c:538:3
> >
> > previously allocated by thread T0 here:
> >     #0 0x564965929c42 in calloc third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
> >     #1 0x5649659e9220 in zalloc tools/lib/zalloc.c:8:9
> >     #2 0x564965c0f32d in mem2node__init tools/perf/util/mem2node.c:61:12
> >     #3 0x564965a08956 in perf_c2c__report tools/perf/builtin-c2c.c:2803:8
> >     #4 0x564965a0616a in cmd_c2c tools/perf/builtin-c2c.c:2989:10
> >     #5 0x564965944348 in run_builtin tools/perf/perf.c:312:11
> >     #6 0x564965943235 in handle_internal_command tools/perf/perf.c:364:8
> >     #7 0x5649659440c4 in run_argv tools/perf/perf.c:408:2
> >     #8 0x564965942e41 in main tools/perf/perf.c:538:3
> >
> > Signed-off-by: Ian Rogers <irogers@google.com>
> > ---
> >  tools/perf/util/mem2node.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/mem2node.c b/tools/perf/util/mem2node.c
> > index 797d86a1ab09..7f97aa69eb65 100644
> > --- a/tools/perf/util/mem2node.c
> > +++ b/tools/perf/util/mem2node.c
> > @@ -95,7 +95,7 @@ int mem2node__init(struct mem2node *map, struct perf_env *env)
> >
> >       /* Cut unused entries, due to merging. */
> >       tmp_entries = realloc(entries, sizeof(*entries) * j);
> > -     if (tmp_entries)
> > +     if (j == 0 || tmp_entries)
>
> nice catch.. I wonder if we should fail in here, or at least
> warn that there're no entris.. which is really strange ;-)

The workload was the stream benchmark with perf c2c, but stream isn't
particularly long running. Not sure how j became 0, there's 2
possibilities in the code. The worry with a warning is the spam, so I
just wanted to make the code correct.

Thanks,
Ian

> thanks,
> jirka
>
> >               entries = tmp_entries;
> >
> >       for (i = 0; i < j; i++) {
> > --
> > 2.25.1.481.gfbce0eb801-goog
> >
>

  reply	other threads:[~2020-03-15  1:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-14  4:28 [PATCH] perf mem2node: avoid double free related to realloc Ian Rogers
2020-03-14 14:23 ` Jiri Olsa
2020-03-14 16:49   ` Ian Rogers [this message]
2020-03-15  9:30     ` Jiri Olsa
2020-03-20 18:25       ` Ian Rogers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP-5=fXZJidxHYeCqHcNPBArMe_aYwP0+u2dxiTD+V1fammK_Q@mail.gmail.com' \
    --to=irogers@google.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.