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 11:37:41 -0400
From:	Michel Dagenais <michel.dagenais@...ymtl.ca>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Martin Bligh <mbligh@...igh.org>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	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,
	fche@...hat.com
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108


> only 5 bytes of NOP are needed by default, so that a kprobe can insert a 
> call/callq instruction. The easiest way in practice is to insert a 
> _single_, unconditional function call that is patched out to NOPs upon 
> its first occurance (doing this is not a performance issue at all). That 
> way the only cost is the NOP and the function parameter preparation 
> side-effects. (which might or might not be significant - with register 
> calling conventions and most parameters being readily available it 
> should be small.)

Interestingly, while this whole thread is full of diverging views, there
is nevertheless considerable common ground.

- Getting a trace output is very useful, whether it is generated from
dynamic or static tracepoints. You need some infrastructure (e.g.
relayfs + a few things) to get the data out efficiently.

- Some sort of static markers make sense in key locations. Whether they
are there "primarily" for dynamic or static tracepoints is mostly
irrelevant. Interesting suggestions were made for a syntax clearly
identifying their "probe point" status.

>>From there we can get onto a constructive debate about the technical
details of each of these components.

> note that such a limited, minimally invasive 'data extraction point' 
> infrastructure is not actually what the LTT patches are doing. It's not 
> even close, and i think you'll be surprised. Let me quote from the 
> latest LTT patch (patch-2.6.17-lttng-0.5.108, which is the same version 
> submitted to lkml - although no specific tracepoints were submitted):

This is a case where it started with inline code but as you take into
account SMP and eventuelly multiple traces (e.g. the sysadmin is tracing
the system and a user is generating a trace for his processes) it
becomes larger and inlining may not be such a good idea any more, to say
the least. However, this is relatively easy to change.

It is also worth mentioning that code patching NOPs to minimize the cost
of inactive tracepoints was envisioned quite some time ago. Again you
might call these "static low overhead placeholders for optimized dynamic
tracepoints" or "optimized low overhead static tracepoints"... You need
however to be careful when code patching instructions on SMP as it may
not be trivial to atomically replace 5 NOPs by a call.

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