[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150114120536.4cccc3a9@gandalf.local.home>
Date: Wed, 14 Jan 2015 12:05:36 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>, vvs@...ru,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>, x86-ml <x86@...nel.org>,
stable@...r.kernel.org
Subject: Re: [PATCH 3/3] ftrace/jprobes/x86: Fix conflict between jprobes
and function graph tracing
On Wed, 14 Jan 2015 17:55:37 +0100
Borislav Petkov <bp@...en8.de> wrote:
> Err, stupid question: marking the jprobe handler "notrace" doesn't help?
>
A few reasons.
One, that would require all users to make their handler as "notrace".
That's not very reliable. Not to mention, I still work at Red Hat and
we have this KABI thingy, where the jprobe modules don't need to change
and we still need to fix it.
This change is much more robust that expecting jprobe callers to add
notrace.
Two, I HATE when a notrace is added for function graph tracing that
is not needed for function tracing. As I told Masami, every "notrace"
added to the kernel makes function tracing that much more useless.
Function tracing should be allowed to debug jprobes.
Three, I have a patch that lets this all work if the kprobe/jprobes
uses the ftrace fentry infrastructure (the work I original did). Why
break everything for something the requires jprobe users to do things
correctly?
-- 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