[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140723132020.23a70e9b@gandalf.local.home>
Date: Wed, 23 Jul 2014 13:20:20 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Namhyung Kim <namhyung@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Jiri Kosina <jkosina@...e.cz>,
Seth Jennings <sjenning@...hat.com>,
Jiri Slaby <jslaby@...e.cz>
Subject: Re: [RFC][PATCH 0/3] ftrace: Add dynamically allocated trampolines
On Wed, 23 Jul 2014 19:05:52 +0200
Oleg Nesterov <oleg@...hat.com> wrote:
> > kprobe ftrace_ops are allocated which sets the FTRACE_OPS_FL_DYNAMIC
> > flag. You'll see that flag checked in update_ftrace_function(), and if
> > it is set, it forces the ftrace_ops_list_func() to be used.
>
> No? __register_ftrace_function() sets if !core_kernel_data(ops), and
> kprobe_ftrace_ops is not dynamic?
Oh, you're right. I thought it was allocated.
What it is missing is the FTRACE_OPS_RECURSION_SAFE flag. Although, I'm
working on a patch that makes a non loop func that does the recursion
checks for just a single ftrace_ops->func if only one is registered.
>
> > Why?
> >
> > [...snip..]
>
> Yes, thanks, I understand why, at least to some degree.
>
> > foo()
> > [mcount called --> ftrace_caller trampoline]
> > ftrace_caller
> > load ftrace_ops into parameter
> > <interrupt>
> > preempt_schedule()
> > [new task]
> > kfree(kprobe ftrace_ops);
>
> see above.
>
> And to be sure, I compiled your rfc/trampoline kernel which I pulled
> yesterday with the same patch and did the same test. __ftrace_ops_list_func()
> prints nothing.
Note, I'm still working on fixes to that branch ;-)
>
> So I also added WARN_ON(1) into kprobe_ftrace_handler() to ensure that
> it is actually called, and yes, dmesg reports
>
> WARNING: ... kprobe_ftrace_handler+0x38/0x140()
> ...
> Call Trace:
> [<ffffffff8136a3eb>] dump_stack+0x5b/0xa8
> [<ffffffff810423ec>] warn_slowpath_common+0x8c/0xc0
> [<ffffffff8105772c>] ? SyS_prctl+0x1c/0x730
> [<ffffffff8104243a>] warn_slowpath_null+0x1a/0x20
> [<ffffffff810325c8>] kprobe_ftrace_handler+0x38/0x140
> [<ffffffff8137148a>] ? retint_swapgs+0xe/0x13
> [<ffffffff81057731>] ? SyS_prctl+0x21/0x730
> [<ffffffff81057731>] ? SyS_prctl+0x21/0x730
> [<ffffffff8122424e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [<ffffffff81370912>] ? system_call_fastpath+0x16/0x1b
>
BTW, you may want to look at
/sys/kernel/debug/tracing/enabled_functions
as that has a lot of debug info for the trampolines in that branch.
> after "perl -e 'syscall 157,-1'".
>
> and, as expected, if I do "echo SyS_prctl >| set_ftrace_filter" and
> "echo function >| current_tracer", then the command above also triggers
> 2 printk's in __ftrace_ops_list_func() :
>
> LIST_FUNC -> function_trace_call()
> LIST_FUNC -> kprobe_ftrace_handler()
>
> so it seems that your patches can potentially buy more than you think ;)
>
> Oleg.
I'll play with this some more to understand everything you are stating.
Thanks,
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists