linux-kernel - Re: [PATCH, RFC 0/3] Improvements to the tracing documentation

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: <20090413213124.GB8514@elte.hu>
Date:	Mon, 13 Apr 2009 23:31:24 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Theodore Tso <tytso@....edu>, Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH, RFC 0/3] Improvements to the tracing documentation

* Theodore Tso <tytso@....edu> wrote:

> On Sun, Apr 12, 2009 at 03:01:05PM +0200, Ingo Molnar wrote:
> > Btw., you mention ext4 and jbd2 new-style tracepoints in the text. 
> > Does this mean you already have them coded up (i havent seen any 
> > patch posting from you), just that you cannot push it upstream yet 
> > because ext4 can be a module? We'll have modular new-style 
> > tracepoints soon.
> 
> Yes, I coded them up recently.  I wanted to do some performance 
> measurements, and being able to interleave the ext4 tracepoint 
> logs with the block I/o tracer was definitely handy.  Also, not 
> having to fight with balky userspace tools (whether it is 
> out-of-tree kernel support code, or random graphical userspace 
> libraries when I could really care less about a GUI interface) was 
> definitely a big win.

Cool. [ And i guess you'll like the per tracepoint filter 
expressions too :-) ]

> I only had two real problems.  One is that the block I/O tracer 
> only traces "real" devices, and not device mapper devices --- I 
> could user the blktrace userspace tool, but then the results 
> wouldn't be properly interleaved with the ext4 tracepoint logs.

Ok - i forwarded your mail to Li Zefan and he already posted a draft 
patch to attempt to solve this. "Cannot trace the primary block 
device my filesystem is using" is IMO a showstopper in your tracing 
work-flow critical path, so it needs some sort of quick solution.

> The second is that ext4 has its localized header files in 
> fs/ext4/*.h, and not in include/linux/*.h, and that was 
> problematic given that the trace code snippets in 
> include/trace/ext4_event_types.h needed access to some internal 
> ext4 data structures.  I ultimately solved the latter by creating 
> a include/linux/ext4_tracing_types.h, but I suspect this problem 
> will go away when you have modular new-style tracepoints --- if 
> not, I'd appreciately greatly if folks could consider whether or 
> not this support could be added.

I'd expect these problems to go away with Steve's module support and 
TRACE_EVENT()-simplification/cleanup series, yes.

> I'll attach the patches as replies to this mail thread so you can 
> see what I've done.  Any comments of anything I might have done 
> "wrong" would be greatly appreciated.

I dont think you can do anything "wrong" at this stage - the event 
tracer is still fresh out of the oven. It was shaped based on the 
needs of a few select core kernel non-modular subsystems (scheduler, 
irqs, etc.). Feedback from people like you with non-trivial 
independent tracing bits (you have a handful of useful-looking 
markers in ext4) is very much needed to shape and complete it.

So we'll sure try to address all your feedback and it would be 
extremely useful if you labeled all the steps that you found 
unintuitive, unnecessary, over-complicated or redundant or painful 
in any way. Please dont hold any of your punches ;-)

	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/