From: Vince Weaver <vincent.weaver@maine.edu>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Vince Weaver <vincent.weaver@maine.edu>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [perf] more perf_fuzzer memory corruption
Date: Tue, 29 Apr 2014 16:59:55 -0400 (EDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1404291534520.22490@vincent-weaver-1.umelst.maine.edu> (raw)
In-Reply-To: <20140429190108.GB30445@twins.programming.kicks-ass.net>
On Tue, 29 Apr 2014, Peter Zijlstra wrote:
> Fair point, nope not in that case. If you can trigger this without ever
> using .inherit=1 this would exclude a lot of funny code.
I don't think inherit is being set, but I'm not actually sure.
I will have to add that to the trace_printk() and recompile/re-run
In the meantime I had a lucky crash and managed to catch a trace.
Unfortunately there's a lot of active events so it's not clear which is
which. I think this is going to need another round of trace generation :(
This trace can be found here:
http://web.eece.maine.edu/~vweaver/junk/bug.out.bz2
A summary:
The troublesome memory address is allocated as part of a perf_event_open
perf_fuzzer-4387 [001] 1802.628663: kmalloc: (perf_event_alloc+0x5a) call_site=ffffffff8113a8fa ptr=0xffff8800a3122800 bytes_req=1272 bytes_alloc=2048 gfp_flags=GFP_KERNEL|GFP_ZERO
The event opened successfully, fd=41, it looks like it is
PERF_COUNT_SW_EMULATION_FAULTS with attr.period=0
perf_fuzzer-4387 [001] 1802.628677: bprint: SYSC_perf_event_open: Opened: 1 8 0
perf_fuzzer-4387 [001] 1802.628677: sys_exit: NR 298 = 41
The parent forks:
perf_fuzzer-4387 [002] 1803.571239: sys_exit: NR 56 = 5504
The event is closed in the parent:
perf_fuzzer-4387 [002] 1803.582345: sys_enter: NR 3 (29, 3000, 3000, 7f7524d760a4, 7f7524d76108, 7f7524d76120)
perf_fuzzer-4387 [002] 1803.582345: sys_exit: NR 3 = 0
The parent kills the child:
perf_fuzzer-4387 [003] 1803.590145: sys_enter: NR 62 (1580, 9, 7, 7f7524d760b8, 7f7524d760b8, 7f7524d76120)
Presumably one of the many perf_swevent_del() calls in the child is us.
perf_fuzzer-5504 [004] 1803.590277: function: perf_swevent_del
*** The parent somehow fails to call perf_swevent_del() on CPU3? ***
The grace period expires and the memory is freed:
ksoftirqd/4-28 [004] 1803.609802: kfree: (free_event_rcu+0x2f) call_site=ffffffff8113177f ptr=0xffff8800a3122800
An event is deleted from swevent_hlist, but ->pprev was our free'd address:
perf_fuzzer-4387 [003] 1803.610555: function: perf_swevent_del
Slab corruption:
[ 1803.610555] ------------[ cut here ]------------
[ 1803.615419] WARNING: CPU: 3 PID: 4387 at include/linux/list.h:620 perf_swevent_del+0x6e/0x90()
[ 1803.948487] Slab corruption (Tainted: G W ): kmalloc-2048 start=ffff8800a3122800, len=2048
[ 1803.958294] 040: 6b 6b 6b 6b 6b 6b 6b 6b 88 f7 92 17 01 88 ff ff kkkkkkkk........
next prev parent reply other threads:[~2014-04-29 20:56 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 21:37 [perf] more perf_fuzzer memory corruption Vince Weaver
2014-04-15 21:49 ` Thomas Gleixner
2014-04-16 3:21 ` Vince Weaver
2014-04-16 4:18 ` Vince Weaver
2014-04-16 14:15 ` Peter Zijlstra
2014-04-16 17:30 ` Vince Weaver
2014-04-16 17:43 ` Vince Weaver
2014-04-16 17:47 ` Peter Zijlstra
2014-04-17 9:48 ` Ingo Molnar
2014-04-17 11:45 ` Peter Zijlstra
2014-04-17 14:22 ` Ingo Molnar
2014-04-17 14:42 ` Vince Weaver
2014-04-17 14:54 ` Peter Zijlstra
2014-04-17 15:35 ` Vince Weaver
2014-04-18 14:45 ` Vince Weaver
2014-04-18 14:51 ` Vince Weaver
2014-04-18 15:23 ` Peter Zijlstra
2014-04-18 16:59 ` Peter Zijlstra
2014-04-18 17:15 ` Peter Zijlstra
2014-04-23 20:58 ` Vince Weaver
2014-04-25 2:51 ` Vince Weaver
2014-04-28 14:21 ` Vince Weaver
2014-04-28 19:38 ` Vince Weaver
2014-04-29 9:46 ` Peter Zijlstra
2014-04-29 18:21 ` Vince Weaver
2014-04-29 19:01 ` Peter Zijlstra
2014-04-29 20:59 ` Vince Weaver [this message]
2014-04-30 18:44 ` Peter Zijlstra
2014-04-30 21:08 ` Vince Weaver
2014-04-30 22:51 ` Thomas Gleixner
2014-05-01 10:26 ` Peter Zijlstra
2014-05-01 11:50 ` Peter Zijlstra
2014-05-01 12:35 ` Thomas Gleixner
2014-05-01 13:12 ` Peter Zijlstra
2014-05-01 13:29 ` Thomas Gleixner
2014-05-01 13:22 ` Vince Weaver
2014-05-01 14:07 ` Vince Weaver
2014-05-01 14:27 ` Vince Weaver
2014-05-01 15:09 ` Peter Zijlstra
2014-05-01 15:50 ` Vince Weaver
2014-05-01 16:31 ` Thomas Gleixner
2014-05-01 17:18 ` Vince Weaver
2014-05-01 18:49 ` Vince Weaver
2014-05-01 21:32 ` Vince Weaver
2014-05-02 11:15 ` Peter Zijlstra
2014-05-02 15:42 ` Peter Zijlstra
2014-05-02 16:22 ` Vince Weaver
2014-05-02 16:22 ` Peter Zijlstra
2014-05-02 16:43 ` Vince Weaver
2014-05-02 17:27 ` Peter Zijlstra
2014-05-02 17:46 ` Vince Weaver
2014-05-02 19:12 ` Thomas Gleixner
2014-05-02 20:15 ` Vince Weaver
2014-05-02 20:45 ` Thomas Gleixner
2014-05-03 2:32 ` Vince Weaver
2014-05-03 3:02 ` Vince Weaver
2014-05-03 7:33 ` Peter Zijlstra
2014-05-05 9:31 ` Peter Zijlstra
2014-05-05 16:00 ` Vince Weaver
2014-05-05 17:10 ` Vince Weaver
2014-05-05 17:14 ` Peter Zijlstra
2014-05-05 18:47 ` Vince Weaver
2014-05-05 19:36 ` Peter Zijlstra
2014-05-05 19:51 ` Vince Weaver
2014-05-06 1:06 ` Vince Weaver
2014-05-06 16:57 ` Vince Weaver
2014-05-07 16:45 ` Peter Zijlstra
2014-05-08 10:40 ` [tip:perf/core] perf: Fix perf_event_init_context() tip-bot for Peter Zijlstra
2014-05-05 17:29 ` [perf] more perf_fuzzer memory corruption Ingo Molnar
2014-05-06 4:51 ` Vince Weaver
2014-05-06 17:06 ` Vince Weaver
2014-05-07 19:12 ` Ingo Molnar
2014-05-07 19:11 ` Ingo Molnar
2014-05-08 10:40 ` [tip:perf/core] perf: Fix race in removing an event tip-bot for Peter Zijlstra
2014-05-02 17:06 ` [perf] more perf_fuzzer memory corruption Vince Weaver
2014-05-02 17:04 ` Peter Zijlstra
2014-04-29 19:26 ` Steven Rostedt
2014-04-29 8:52 ` Peter Zijlstra
2014-04-29 18:11 ` Vince Weaver
2014-04-29 19:21 ` Steven Rostedt
2014-04-28 17:48 ` Thomas Gleixner
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=alpine.DEB.2.10.1404291534520.22490@vincent-weaver-1.umelst.maine.edu \
--to=vincent.weaver@maine.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.