linux-kernel - Re: [RFC][PATCH 00/13] ftrace: Allow multiple users to pick and choose functions to trace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110510080029.GA27426@elte.hu>
Date:	Tue, 10 May 2011 10:00:29 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Li Zefan <lizf@...fujitsu.com>, Jiri Olsa <jolsa@...hat.com>,
	David Sharp <dhsharp@...gle.com>,
	Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
	Michael Rubin <mrubin@...gle.com>
Subject: Re: [RFC][PATCH 00/13] ftrace: Allow multiple users to pick and
 choose functions to trace


* Steven Rostedt <rostedt@...dmis.org> wrote:

> 
> Ingo, et. al.
> 
> This is an RFC patch set of the work I did to allow multiple users
> to pick and choose which functions they would like to trace without
> being affected by other users (well, they are still affected, but
> they can choose their own functions).
> 
> Since this rewrote a lot of the guts of ftrace's function handling
> I broke it up into steps that I can sequentially think about how to
> make the conversion. It also helped in understanding the changes that
> had to be made.
> 
> The end result now has this:
> 
>  o The function record list flags item now stores a ref count, and
>    we no longer need to have the flags if the records are filtered
>    or set for "notrace"
> 
>  o Each ftrace_ops has its own set of functions to trace or not trace
>    which is used to update the ref counts of the function records
>    mentioned above. If the ftrace_ops is not currently active, the
>    records are not touched when the filters are changed. If the filters
>    are changed while the ftrace_ops is active, it is done in a way
>    with RCU to make the updates.
> 
>  o If only one ftrace_ops is registered for tracing (actively tracing),
>    its handler is called directly from mcount. Unless the ftrace_ops
>    was allocated and not a static/global core kernel variable (see below).
> 
>  o If more than one ftrace_ops is registered, then a function is called
>    that will iterate over the list of registered ftrace_ops, performing
>    a check of each of its hashes to know if ftrace_ops handler should
>    be called for that function.
> 
>  o If a ftrace_ops is allocated and not a static/global core kernel
>    variable, it will be forced to use the function that loops through
>    the ftrace_ops even if its the only one. This is because that function
>    disables preemption when it performs the loop. This is needed, because
>    dynamically allocated ftrace_ops must call synchronize_sched() before
>    being freed (which is done when the dynamic ftrace_ops has been
>    unregistered).
> 
>  o A file has been created in the debugfs/tracing directory called
>    enabled_functions. This file contains a list of all functions that
>    any ftrace_ops has registered, along with each functions ref count.
>    This can be used to make sure nothing is tracing.

Well, i think we'd like to see the end result as well: i.e. function tracing 
exposed to a tracer that can do per task tracing (perf) and then demonstrating 
that independent tracing sessions can trace functions without impacting each 
other.

Thanks,

	Ingo
--
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/