Re: [perf] more perf_fuzzer memory corruption

[Vince Weaver]

On Thu, 24 Apr 2014, Vince Weaver wrote:

> [ 2226.257503] WARNING: CPU: 4 PID: 0 at lib/debugobjects.c:260 debug_print_object+0x83/0xa0()
> [ 2226.266545] ODEBUG: free active (active state 0) object type: hrtimer hint: perf_swevent_hrtimer+0x0/0x140
> [ 2226.389820] Call Trace:
> [ 2226.392428]  <IRQ>  [<ffffffff8164f7b3>] dump_stack+0x45/0x56
> [ 2226.398595]  [<ffffffff810647cd>] warn_slowpath_common+0x7d/0xa0
> [ 2226.405059]  [<ffffffff8106483c>] warn_slowpath_fmt+0x4c/0x50
> [ 2226.411240]  [<ffffffff813cc9e3>] debug_print_object+0x83/0xa0
> [ 2226.417535]  [<ffffffff81139200>] ? __perf_event_overflow+0x270/0x270
> [ 2226.424463]  [<ffffffff813cde73>] debug_check_no_obj_freed+0x263/0x360
> [ 2226.431500]  [<ffffffff811316aa>] ? free_event_rcu+0x2a/0x30
> [ 2226.437579]  [<ffffffff81196fd0>] kfree+0xb0/0x560
> [ 2226.442740]  [<ffffffff810ccd46>] ? rcu_process_callbacks+0x236/0x620
> [ 2226.449658]  [<ffffffff81131680>] ? pmu_dev_release+0x10/0x10
> [ 2226.455811]  [<ffffffff811316aa>] free_event_rcu+0x2a/0x30
> [ 2226.461727]  [<ffffffff810ccdad>] rcu_process_callbacks+0x29d/0x620
> [ 2226.468440]  [<ffffffff810ccd46>] ? rcu_process_callbacks+0x236/0x620
> [ 2226.475384]  [<ffffffff81069ab5>] __do_softirq+0xf5/0x290
> [ 2226.481210]  [<ffffffff81069e9d>] irq_exit+0xad/0xc0
> [ 2226.486540]  [<ffffffff81662e35>] smp_apic_timer_interrupt+0x45/0x60
> [ 2226.493350]  [<ffffffff8166181d>] apic_timer_interrupt+0x6d/0x80
> [ 2226.499798]  <EOI>  [<ffffffff810d958e>] ? tick_nohz_idle_exit+0x12e/0x1b0
> [ 2226.507192]  [<ffffffff810aa7de>] cpu_startup_entry+0x12e/0x3d0
> [ 2226.513542]  [<ffffffff81042a43>] start_secondary+0x193/0x200
> [ 2226.519706] ---[ end trace ec55e71b02ef43b3 ]---

so it's looking more and more like this issue is with a
	PERF_COUNT_SW_TASK_CLOCK
event.

It's being deallocated in a different process than it was started (due to 
fork).

And it really looks like the problem is even though the event is free'd, 
there's still an active hrtimer associated with it somehow.

I can't seem to find *why* there's an associated hrtimer though, as the 
event as far as I can tell was created with sample_period=0 and the 
various
	perf_swevent_init_hrtimer()
calls seem to guard with is_sampling()

This is made all the more confusing because the PERF_COUNT_SW_TASK_CLOCK 
events are handled by their own PMU even though it's faked up so they look 
like regular software events.  Is there a reason for that?

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/