Messages in this thread | | | Subject | Re: [PATCH 02/11] [BUGFIX] ftrace, kprobes: Fix a deadlock on ftrace_regex_lock | From | Steven Rostedt <> | Date | Thu, 09 May 2013 10:47:09 -0400 |
| |
On Thu, 2013-05-09 at 14:44 +0900, Masami Hiramatsu wrote: > Fix a deadlock on ftrace_regex_lock which happens when setting > an enable_event trigger on dynamic kprobe event as below. > > ---- > sh-2.05b# echo p vfs_symlink > kprobe_events > sh-2.05b# echo vfs_symlink:enable_event:kprobes:p_vfs_symlink_0 > set_ftrace_filter > > ============================================= > [ INFO: possible recursive locking detected ] > 3.9.0+ #35 Not tainted > --------------------------------------------- > sh/72 is trying to acquire lock: > (ftrace_regex_lock){+.+.+.}, at: [<ffffffff810ba6c1>] ftrace_set_hash+0x81/0x1f0 > > but task is already holding lock: > (ftrace_regex_lock){+.+.+.}, at: [<ffffffff810b7cbd>] ftrace_regex_write.isra.29.part.30+0x3d/0x220 > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(ftrace_regex_lock); > lock(ftrace_regex_lock);
Ouch! I'm surprised I didn't trigger this in my tests. I have lockdep enabled, and I did run kprobe testing. I'll have to look at how this was missed :-/
> > *** DEADLOCK *** > ---- > > To fix that, this introduces a finer regex_lock for each ftrace_ops. > ftrace_regex_lock seems that a big lock which protect all > filter/notrace_hash operation, but it doesn't need to be a global > lock after supporting multiple ftrace_ops because each ftrace_ops > has its own filter/notrace_hash.
OK, I'll test this patch out and see how it goes. I first need to see how it broke without this patch.
Thanks,
-- Steve
| |