linux-kernel - Re: [PATCH 6/7] kmemtrace: restore original tracing data binary format, improve ABI

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]

Date:	Mon, 23 Mar 2009 16:06:13 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
Cc:	rostedt@...dmis.org, compudj@...stal.dyndns.org,
	fweisbec@...il.com, penberg@...helsinki.fi,
	paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/7] kmemtrace: restore original tracing data binary
	format, improve ABI


* Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro> wrote:

> When kmemtrace was ported to ftrace, the marker strings were taken 
> as an indication of how the traced data was being exposed to the 
> userspace. However, the actual format had been binary, not text.
> 
> This restores the original binary format, while also adding an 
> origin CPU field (since ftrace doesn't expose the data per-CPU to 
> userspace), and re-adding the timestamp field. It also drops 
> arch-independent field sizing where it didn't make sense, so 
> pointers won't always be 64 bits wide like they used to.

Thanks Eduard, nice stuff! I'll pick up your patches as they are 
nice fixes and cleanups but you might want to take a look at a few 
things that happened in tracing land in the past few weeks:

firstly, you can now fetch data in a per CPU way:

[root@...ebaran tracing]# pwd
/debug/tracing
[root@...ebaran tracing]# ll per_cpu/
total 0
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu0
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu1
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu10
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu11
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu12
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu13
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu14
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu15
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu2
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu3
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu4
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu5
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu6
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu7
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu8
drwxr-xr-x 2 root root 0 2009-03-23 10:44 cpu9
[root@...ebaran tracing]# ll per_cpu/cpu0/
total 0
-rw-r--r-- 1 root root 0 2009-03-23 10:44 trace
-r--r--r-- 1 root root 0 2009-03-23 10:44 trace_pipe
-r--r--r-- 1 root root 0 2009-03-23 10:44 trace_pipe_raw

This is a relatively new addition. The trace_pipe_raw file can be 
used to fetch binary data, and it has working splice() support as 
well, for zero-copy data streaming.

To get those binary records the tracepoint has to be expressed not 
in terms of DEFINE_TRACE(), but in terms of DEFINE_EVENT(). See a 
few examples in:

  include/trace/irq_event_types.h
  include/trace/sched_event_types.h

With latest -tip you can also define simple in-situ filters on each 
tracepoint, via the 'filter' file. I think this capability would be 
particularly interesting for kmemtrace, to restrict tracing to a 
given cache only, to particular sizes, etc.

This too needs DEFINE_EVENT() definition. It's more elaborate to 
express tracepoints via DEFINE_EVENT() than via 
DECLARE/DEFINE_TRACE(), but it results in faster tracing and enables 
more built-in features.

See this commit in -tip:

 | commit 7ce7e4249921d5073e764f7ff7ad83cfa9894bd7
 | Author: Tom Zanussi <tzanussi@...il.com>
 | Date:   Sun Mar 22 03:31:04 2009 -0500
 |
 |     tracing: add per-event filtering

for a short description about how these filters work.

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/