Messages in this thread | | | Date | Thu, 14 May 2015 22:37:56 -0700 | From | Alexei Starovoitov <> | Subject | Re: [BUG] kernel panic after bpf program removed. |
| |
On 5/14/15 8:54 PM, Wangnan (F) wrote: > Hi Alexei Starovoitov and other, > > I triggered a kernel panic when developing my 'perf bpf' facility. The > call stack is listed at the bottom of > this mail. > > I attached two bpf programs on 'kmem_cache_free%return' and > '__alloc_pages_nodemask'. The programs is very simple. > The panic is raised after closing the bpf program and the perf event > file. Looks like the panic is caused > by racing between closing perf event fd and bpf program fd. I'm unable > to reproduce this problem with similar > operations. > > Following is the exact instruction cause the panic.
thanks for the report. Looks like pointer 'prog == 0x6c0' is passed into bpf_prog_put, which means that event->tp_event was freed and memory reused before free_event_rcu() was called.
I think it's not perf_event_fd racing with prog_fd, but rather with kprobe freeing: __free_event() event->destroy(event) perf_trace_destroy perf_trace_event_unreg which is dropping event->tp_event->perf_refcount that allows kprobe freeing to proceed in: unregister_kprobe_event trace_remove_event_call probe_remove_event_call and eventually tp_event to get freed.
I think calling perf_event_free_bpf_prog() from __free_event() instead of free_event_rcu() will fix the race, but please double check my analysis. Also please send me a reproducer script. I'd like to see it crashing first before the fix and not crashing afterwards.
| |