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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Sep 2006 21:37:13 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Andrew Morton <akpm@...l.org>
Cc:	tglx@...utronix.de, karim@...rsys.com,
	Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Ingo Molnar <mingo@...e.hu>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.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

Ar Gwe, 2006-09-15 am 11:16 -0700, ysgrifennodd Andrew Morton:
> What Karim is sharing with us here (yet again) is the real in-field
> experience of real users (ie: not kernel developers).

A lot of us have plenty of experience helping customers and end users
trace bugs. Thats a good part of why we get paid in the first place.

> What I _am_ concerned about with this patchset is all the infrastructural
> goop which backs up those tracepoints.  I'd have thought that a better
> approach would be to make those explicit tracepoints be "helpers" for the
> existing kprobe code.

If you put explicit tracepoints in they will be compiled out for end
users. If you have a script which hits the standard tracepoint set it'll
be usable by end users.

> Of course, it they are properly designed, the one set of tracepoints could
> be used by different tracing backends - that allows us to separate the
> concepts of "tracepoints" and "tracing backends".

There are more than two layers. The first question is "how do I trace
event XYZ" which seems to be the big debate. The second is "how do I
find XYZ" which seems to have some commonality. The third is "what do I
do when the event is hit", which kprobes provides to all the existing
consumers such as systemtap and can field into arrays for graph plotting
and the like.

Ignoring the question of static compiled in trace points kprobes appears
to have solved the problem space. Everyone else can use the kprobes
interfaces to do pretty much anything computationally viable.

I am sceptical about static tracepoints in critical spots because if
they make the variable easy to access they will reduce optimisations and
that will cost a lot more than 5 or 6 clocks.

In addition ideally we want a mechanism that is also sufficient that
printk can be mangled into so that you can pull all the printk text
strings _out_ of the kernel and into the debug traces for embedded work.

[ie you want printk("Oh dear %s exploded.\n", foo->bar); to end up with
"Oh dear %s exploded.\n" out of kernel and in kernel

		tracepoint_printk(foo->bar);

maybe with minimal type info (although that can be pulled at debug time
from the string spat into the debug data).]

Alan

-
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/