Date: Mon, 11 Feb 2008 17:31:38 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org,
       Linus Torvalds <torvalds@linux-foundation.org>,
       Andrew Morton <akpm@zip.com.au>
Subject: Re: [17/19] ftrace: dynamic enabling/disabling of function calls
Message-ID: <20080211163138.GA2272@elte.hu>
References: <20080210072109.GR4100@elte.hu> <47B06B4E.1010704@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47B06B4E.1010704@redhat.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1209
Lines: 26


* Masami Hiramatsu <mhiramat@redhat.com> wrote:

> > Because we do this via stop_machine, we don't have to worry about 
> > another CPU executing a ftrace call as we modify it. But we do need 
> > to worry about NMI's so all functions that might be called via nmi 
> > must be annotated with notrace_nmi. When this code is configured in, 
> > the NMI code will not call notrace.
> 
> I'd like to suggest that you can use djprobe-like solution here to 
> eliminate stop_machine. The djprobe makes a bypass over that call 
> instruction by using a kprobe, and after replacing the call 
> instruction, you can safely remove the bypass. [...]

i think the stop_machine() method for code patching is pretty elegant in 
that it reuses an otherwise rarely used but critical facility. We want 
it to be fast and easy, and our current ftrace testing shows that it is. 
So unless there are strong reasons to do otherwise, it would be nice to 
keep that approach :-)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/