From: Masami Hiramatsu <mhiramat@redhat.com>
To: rostedt@goodmis.org
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>, Li Zefan <lizf@cn.fujitsu.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
"David S. Miller" <davem@davemloft.net>,
Stephen Hemminger <shemminger@linux-foundation.org>
Subject: Re: [PATCH 0/3][RFC] tracing/kprobes: prevent jprobes from crashing function graph tracer
Date: Thu, 29 Oct 2009 19:22:19 -0400 [thread overview]
Message-ID: <4AEA23AB.9020605@redhat.com> (raw)
In-Reply-To: <1256854653.26028.3255.camel@gandalf.stny.rr.com>
Steven Rostedt wrote:
> On Thu, 2009-10-29 at 18:02 -0400, Masami Hiramatsu wrote:\
>>> The solution I am proposing with this patch set is to add a call in
>>> ftrace that lets other code in the kernel permanently disable functions from
>>> being traced by the function and function graph tracer. As a probe function
>>> is registered with jprobes, it calls this new function and that entry
>>> will be removed from being traced.
>>>
>>> I tested this with this patch series and it does solve the problem.
>>>
>>> Some issues though:
>>>
>>> 1) this only works when DYNAMIC_FTRACE is enabled. We can prevent
>>> function graph tracing with jprobes when DYNAMIC_FTRACE is not
>>> enabled through Kconfig dependencies. Or have the registering of
>>> a jprobe permanently disable function graph tracing.
>>
>> IMHO, those *probe handler should be tagged as __kprobes and notrace.
>
> Yeah, I agree. But how do you guarantee that it does. If one forgets,
> than we still have the issue. We can perhaps test to make sure the
> function is in the kprobes section. But that does not mean they will not
> be notraced. The __kprobes and notrace are no longer in the same set.
>
>>
>>> 2) This also prevents the function tracer from being able to trace a
>>> function probe, even though the function tracer is not at issue
>>> with this bug.
>>
>> I think we can skip those user handlers, because those are irregular
>> functions and user can control (enable/disable) it.
>
> True, but it may be nice to still trace them.
Hm, in that case, I think we can change jprobe_return() to call
f-g-tracer's return handler if needed as below;
---
static inline jprobe_return(void)
{
implicit_function_return(); /* This executes f-g-tracer prologue */
__jprobe_return(); /* This should be notraced */
}
---
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
next prev parent reply other threads:[~2009-10-29 23:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-29 20:51 [PATCH 0/3][RFC] tracing/kprobes: prevent jprobes from crashing function graph tracer Steven Rostedt
2009-10-29 20:51 ` [PATCH 1/3][RFC] [PATCH 1/3] tracing: Clean up ftrace.h header and add ftrace_set_notrace() declaration Steven Rostedt
2009-10-29 20:51 ` [PATCH 2/3][RFC] [PATCH 2/3] tracing: Add calls to permanently disable functions from tracing Steven Rostedt
2009-10-29 20:51 ` [PATCH 3/3][RFC] [PATCH 3/3] tracing/kprobes: Disable tracing registered jprobe callback functions Steven Rostedt
2009-10-29 22:02 ` [PATCH 0/3][RFC] tracing/kprobes: prevent jprobes from crashing function graph tracer Masami Hiramatsu
2009-10-29 22:17 ` Steven Rostedt
2009-10-29 22:26 ` Stephen Hemminger
2009-10-29 23:22 ` Masami Hiramatsu [this message]
2009-10-30 0:06 ` Steven Rostedt
2009-10-30 0:49 ` Masami Hiramatsu
2009-11-02 0:37 ` Frederic Weisbecker
2009-11-02 15:02 ` Masami Hiramatsu
2009-11-02 20:22 ` Frederic Weisbecker
2009-11-02 20:30 ` Masami Hiramatsu
2009-10-31 20:06 ` Frank Ch. Eigler
2009-11-01 14:48 ` Masami Hiramatsu
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=4AEA23AB.9020605@redhat.com \
--to=mhiramat@redhat.com \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=shemminger@linux-foundation.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.