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]

Date:	Wed, 17 Nov 2010 12:35:50 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	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>,
	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'

On Wed, 2010-11-17 at 09:30 +0100, Ingo Molnar wrote:
> * 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.

I don't see the point, the kernel shouldn't contain any trace_printk()s
to begin with..
--
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/