From: Jiri Olsa <jolsa@redhat.com>
To: Stephane Eranian <eranian@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
mingo@elte.hu
Subject: Re: [PATCH] perf ordered_events: fix crash in free_dup_event()
Date: Thu, 9 Aug 2018 09:39:45 +0200 [thread overview]
Message-ID: <20180809073945.GA19243@krava> (raw)
In-Reply-To: <CABPqkBRwG_MzfJp1d7+4JKNemoD9cOWqJnXaBWQNR7buESKm2w@mail.gmail.com>
On Wed, Aug 08, 2018 at 02:47:42PM -0700, Stephane Eranian wrote:
> Hi,
>
> Ok, I found the problem. It still exists upstream , just very tricky to trigger.
> Took me lots of time with gdb + watchpoints to track this down, where
> in fact it was just in front of me.
>
> From the crashdump:
> Program received signal SIGSEGV, Segmentation fault.
> free_dup_event (oe=0x26a39a0, event=0xffffffff00000000)
>
> I was puzzled by the 0xffffffff00000000. I tracked down where this
> value was coming from using watchpoints.
> In my case the memory was used before by elfutils to back the struct
> Elf. The -1 in the upper bits came from:
>
> file_read_elf () at third_party/elfutils/libelf/elf_begin.c:451
> elf->state.elf64.scns.data[cnt].shndx_index = -1;
>
> And yet the next access to that memory location was in the crash. That
> meant the memory was released by
> elfutils and reused by ordered_events, yet without any initialization.
> But looking at alloc_event(), it was
> not obvious to figure out how a new_event->event could be uninitialized.
>
> Well, it turns out there is this little hack where the code
> commandeers the first element in the oe->buffer to
> use as a list_head for the oe->to_free freelist. The problem is that
> this entry also gets freed, but its
> event->event field is NEVER initialized. So depending on how the
> memory was previously used, you
> could get a on NULL value and crash in free_dup_event(). This is what
> happened to me. I am glad
> I pursued this further because the bug is still in the upstream
> version. The patch is a one-liner fixing
> the initialization of the event->event = NULL. For the other elements
> in the list, the initialization is
> already done at the end of alloc_event().
>
> I will send the patch separately.
nice ;-) thanks
jirka
prev parent reply other threads:[~2018-08-09 7:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 1:23 [PATCH] perf ordered_events: fix crash in free_dup_event() Stephane Eranian
2018-08-07 7:20 ` Jiri Olsa
2018-08-07 8:16 ` Stephane Eranian
2018-08-07 8:50 ` Jiri Olsa
2018-08-07 19:11 ` Stephane Eranian
2018-08-08 8:23 ` Jiri Olsa
2018-08-08 21:47 ` Stephane Eranian
2018-08-09 7:39 ` Jiri Olsa [this message]
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=20180809073945.GA19243@krava \
--to=jolsa@redhat.com \
--cc=acme@redhat.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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.