linux-kernel - Re: tracepoint maintainance models

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: <20060918152230.GA12631@elte.hu>
Date:	Mon, 18 Sep 2006 17:22:30 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jes Sorensen <jes@....com>, Andrew Morton <akpm@...l.org>,
	Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>,
	"Martin J. Bligh" <mbligh@...igh.org>
Subject: Re: tracepoint maintainance models


* Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> > also, there should be only a single switch for markups: either all 
> > of them are compiled in or none of them. That simplifies the support 
> > picture and gets rid of some ugly #ifdefs. Distro kernels will 
> > likely enable all of thems, so there will be nice uniformity all 
> > across.
> 
> I think your implementation is questionable if it causes any kind of 
> jumps and conditions, even marked unlikely. Just put the needed data 
> in a seperate section which can be used by the debugging tools. No 
> need to actually mess with the code for the usual cases.

yeah - but i think to make it easier for SystemTap to insert a 
low-overhead probe there needs to be a 5-byte NOP inserted. There wont 
be any function call or condition at that place. At most there will be 
some minimal impact on the way gcc compiles the code in that function, 
to make sure that the data is not optimized out and is available to 
SystemTap. For example at the point of the probe gcc might already have 
destroyed a register-passed function parameter. (but normally there 
should be any effect, because it's pointless to trace data that gcc 
optimizes out.)

	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/