linux-kernel - Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060915194937.GA7133@Krystal>
Date:	Fri, 15 Sep 2006 15:49:37 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	"Jose R. Santos" <jrs@...ibm.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Tim Bird <tim.bird@...sony.com>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

* Jose R. Santos (jrs@...ibm.com) wrote:
> Alan Cox wrote:
> 
> With several other trace tools being implemented for the kernel, there 
> is a great problem with consistencies among these tool.  It is my 
> opinion that trace are of very little use to _most_ people with out the 
> availability of post-processing tools to analyses these trace.  While I 
> wont say that we need one all powerful solution, it would be good if all 
> solutions would at least be able to talk to the same post-processing 
> facilities in user-space.  Before LTTng is even considered into the 
> kernel, there need to be discussion to determine if the trace mechanism 
> being propose is suitable for all people interested in doing trace 
> analysis.  The fact the there also exist tool like LKET and LKST seem to 
> suggest that there other things to be considered when it comes to 
> implementing a trace mechanism that everyone would be happy with.
> 
> It would also be useful for all the trace tool to implement the same 
> probe points so that post-processing tools can be interchanged between 
> the various trace implementations.
> 
> 

Hi Jose,

I completely agree that there is a crying need for standardisation there. The
reason why I propose the LTTng infrastructure as a tracing core in the Linux
kernel is this : the fundamental problem I have found with kernel tracers so
far is that they perturb the system too much or do not offer enough fine
grained protection against reentrancy. Ingo's post about tracing statement
breaking the kernel all the time seems to me like a sufficient proof that this
is a real problem.

My goal with LTTng is to provide a reentrant data serialisation mechanism that
can be called from anywhere in the kernel (ok, the vmalloc path of the page
fault handler is _the_ exception) that does not use any lock and can therefore
trace code paths like NMI handlers.

I also implemented code that would serialize any type of data structure I could
think of. If it is too much, well, we can use part of it.

LTTng trace format is explained there. Your comments on it are very welcome.

http://ltt.polymtl.ca/ > LTTV and LTTng developer documentation > format.html
(http://ltt.polymtl.ca/svn/ltt/branches/poly/doc/developer/format.html)

Regards,

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 
-
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/