Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753564AbaGGN6d (ORCPT ); Mon, 7 Jul 2014 09:58:33 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60568 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753219AbaGGN6b (ORCPT ); Mon, 7 Jul 2014 09:58:31 -0400 Date: Mon, 7 Jul 2014 15:58:28 +0200 (CEST) From: Jiri Kosina To: Steven Rostedt cc: linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , Thomas Gleixner , "Paul E. McKenney" , Masami Hiramatsu , Namhyung Kim , "H. Peter Anvin" , Oleg Nesterov , Josh Poimboeuf , Seth Jennings , Jiri Slaby Subject: Re: [RFC][PATCH 0/3] ftrace: Add dynamically allocated trampolines In-Reply-To: <20140703200750.648550267@goodmis.org> Message-ID: References: <20140703200750.648550267@goodmis.org> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jul 2014, Steven Rostedt wrote: > [ NOT READY FOR INCLUSION! ] > > Note, this is based off of my remove ftrace_start/stop() patch set. > > I've been wanting to do this for years, and just never gotten around to it. > But with all this talk of kpatch and kgraft live kernel patching using > the ftrace infrastructure, it seems like a good time to do it. > > The way the function callback mechanism works in ftrace is that if there's > only one function callback registered, it will set the mcount/fentry > trampoline to call that function directly. But as soon as you register > another callback, the mcount trampoline calls a loop function that iterates > over all the registered callbacks (ftrace_ops) checking their hash tables > to see if the called function matches the ops before calling its callback. > This happens even if the two registered functions are not even tracing > the same function! > > This really sucks if you are tracing all functions, and then add a kprobe > or perf event that traces a single function. That will cause all the > other functions being traced to perform the loop test. [ ... snip ... ] For the record -- I just did a quick test, and kGraft works nicely on top of this patchset. Will be looking into the patches more closely later this week. -- Jiri Kosina SUSE Labs -- 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/