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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ