linux-kernel - Re: [PATCH] Linux Kernel Markers

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:	Tue, 19 Sep 2006 10:11:24 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	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>, ltt-dev@...fik.org,
	systemtap@...rces.redhat.com, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] Linux Kernel Markers

* Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:

> +choice
> +	prompt "MARK code marker behavior"

> +config MARK_KPROBE
> +config MARK_JPROBE
> +config MARK_FPROBE
> +	Change markers for a function call.
> +config MARK_PRINT

as indicated before in great detail, NACK on this profileration of 
marker options, especially the function call one. I'd like to see _one_ 
marker mechanism that distros could enable, preferably with zero (or at 
most one NOP) in-code overhead. (You can of course patch whatever 
extension ontop of it, in out-of-tree code, to gain further performance 
advantage by generating direct system-calls.)

There might be a hodgepodge of methods and tools in userspace to do 
debugging, but in the kernel we should get our act together and only 
take _one_ (or none at all), and then spend all our efforts on improving 
that primary method of debug instrumentation. As kprobes/SystemTap has 
proven, it is possible to have zero-overhead inactive probes.

Furthermore, for such a patch to make sense in the upstream kernel, 
downstream tracing code has to make actual use of that NOP-marker. I.e. 
a necessary (but not sufficient) requirement for upstream inclusion (in 
my view) would be for this mechanism to be used by LTT and LKST. (again, 
you can patch LTT for your own purposes in your own patchset if you 
think the performance overhead of probes is too much)

	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/