linux-kernel - Re: [ANNOUNCE] New utility: '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: <20101117083020.GA11336@elte.hu>
Date:	Wed, 17 Nov 2010 09:30:20 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Darren Hart <dvhart@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Jason Baron <jbaron@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Christoph Hellwig <hch@....de>,
	Pekka Enberg <penberg@...nel.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [ANNOUNCE] New utility: 'trace'


* Frederic Weisbecker <fweisbec@...il.com> wrote:

> On Tue, Nov 16, 2010 at 01:27:35PM -0800, Darren Hart wrote:
> > On 11/16/2010 01:04 PM, Thomas Gleixner wrote:
> >> We are pleased to announce a new tracing tool called 'trace'.
> >>
> >
> > Hi Thomas, Ingo - Congrats and Thanks!
> >
> >> At this point we'd like to ask for feedback from other users of tracing tools,
> >> which workflow components would you like to see in addition to what the 'trace'
> >> tool is offering?
> >>
> >> Comments, bug reports, suggestions welcome,
> >
> > The first thing that comes to mind is trace_marker:
> >
> > echo "Test point A" > /sys/kernel/debug/tracing/trace_marker
> >
> > I've found this sort of markup to be useful using ftrace (with C  
> > equivalents embedded in the test case). Is this supported?
> 
> 
> No, the trace_marker file sends trace_printk events. And trace_printk
> events needs to be converted to use the unified trace event interface
> (ie: implement a struct ftrace_event_call).
> 
> This shouldn't be so hard, and there are several ways we could do this.
> 
> An idea is to reproduce the kernel file hierarchy in a "printk" event
> subsystem, but this implies to allow subsystems nesting.
> 
> Imagine you have two trace_printk(), one in kernel/sched.c:117
> and one in kernel/time/tick-sched.c:228
> The result would be:
> 
> $ ls /sys/kernel/debug/tracing/events/printk
> 
> /sys/kernel/debug/tracing/events/printk:
> enable  filter  kernel/
> 
> /sys/kernel/debug/tracing/events/printk/kernel:
> enable  filter sched.c/ time/
> 
> /sys/kernel/debug/tracing/events/printk/kernel/sched.c:
> enable  filter  117/
> 
> /sys/kernel/debug/tracing/events/printk/kernel/sched.c/117:
> enable filter format id
> 
> /sys/kernel/debug/tracing/events/printk/kernel/time:
> enable  filter tick-sched.c/
> 
> /sys/kernel/debug/tracing/events/printk/kernel/time/tick-sched.c:
> enable  filter  228/
> 
> /sys/kernel/debug/tracing/events/printk/kernel/time/tick-sched.c/228:
> enable filter format id
> 
> 
> The format would be quite easy, and only one field for the whole string (strloc).
> 
> Not sure what to do with trace_marker. I just think we can add it as:
> /sys/kernel/debug/tracing/events/printk/sys/kernel/debug/tracing/trace_marker
> 
> <:o)
> 
> 
> But may be the whole idea is just fancy and nobody will care, [...]

I think it's an excellent idea, and it could also give us the framework to integrate 
the dynamic_printk points.

> [...] and would just a simple single event in a printk subsystem, on which you can 
> use a kind of virtual filter:
> 
> 	echo "path != kernel/whatever.c:226" > /sys/kernel/debug/tracing/events/printk/filter
> 
> would turn on every trace_printk() but the one in the given path.
> 
> Dunno, I like both ideas. I prefer the first one which looks to me more flexible: 
> could be useful to list the user his trace_printks for example and implement an 
> interface for him to quickly select the trace_printk he wants.

I prefer the first one too.

> For example I'm currently working with dozens of trace_printk() and I would be 
> very happy to turn some of them off half of the time.

I guess we could try such a patch. If you send a prototype i'd be interested in 
testing it out.

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/