linux-kernel - [PATCH 0/2] tracing: Tracing integration

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4AAF6724.9080201@bk.jp.nec.com>
Date:	Tue, 15 Sep 2009 19:06:28 +0900
From:	Atsushi Tsuji <a-tsuji@...jp.nec.com>
To:	linux-kernel@...r.kernel.org, rostedt@...dmis.org,
	Ingo Molnar <mingo@...e.hu>, fweisbec@...il.com,
	"Frank Ch. Eigler" <fche@...hat.com>
CC:	Peter Zijlstra <peterz@...radead.org>, paulus@...ba.org,
	systemtap@...rces.redhat.com
Subject: [PATCH 0/2] tracing: Tracing integration - dynamic ftrace for SystemTap

Hi,

Currently, there are some tracers using in Linux. Each of them are
developed for different users and situations.

Ftrace has own probe mechanism, dynamic ftrace, and various plugins,
and it can be used without particular userland tools. It is suitable
for kernel developer. The performance counters have own userland tool
merged in the kernel tree and it's easy to trace kernel events by using
this tool. It is suitable for people who don't have enough knowledge
of internal kernel. SystemTap has own scripting language and users can
gather kernel internal information suited to their needs by customizing
the script. Since it also has features, the log rotation and the
initscript, to keep collecting information continually, it is suitable
for system administrator and enterprise users.

I think we need to use those tracers as the situation demands, since
no tracer exists to meet anyone's needs and to fit any situation.
Then, we should consider the tracing mechanisms (kprobe, dynamic ftrace
and etc. kernel tracing features) and tracers (user interface)
separately, and all tracers should be able to use each tracing mechanisms.

The mechanism of dynamic ftrace is useful for all tracers. However
only ftrace can currently use it. I think it can be used for other
tracers via register_ and unregister_ftrace_function_probe
function. By using it, the overhead of instrumentation can be reduced
and gathering information, which cannot be traced because of a large
overhead, become available. Also it can enable the performance
counters to count events for all kernel functions.

First, I sent patches to integrate ftrace and SystemTap by just exporting
ftrace API. Also I fixed minor bugs for __unregister_ftrace_function_probe.

The patches doesn't contain the performance counters integration,
since it is still in development. I think following implementations are
needed:
- add new type to perf_id (like PERF_TYPE_FTRACE)
- add event ids to struct dyn_ftrace
- add interfaces to reference event ids by user (via debugfs?)
- add probe function to count ftrace events (call do_perf_swcounter_event)

Those patches are for -tip tree.

Thanks,
Atsushi

Signed-off-by: Atsushi Tsuji <a-tsuji@...jp.nec.com>
---
 kernel/trace/ftrace.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

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