linux-kernel - Re: [patch 34/37] LTTng instrumentation ipc

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] [day] [month] [year] [list]

Message-ID: <20080504203920.GE23961@redhat.com>
Date:	Sun, 4 May 2008 16:39:20 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	akpm@...ux-foundation.org, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 34/37] LTTng instrumentation ipc

Hi -

On Mon, May 05, 2008 at 01:04:33AM +0400, Alexey Dobriyan wrote:
> [...]
> > for the rest, a way that would not export too much information about
> > kernel's internals :
> > 
> > trace_mark(shm_start, "is_shm_fop %d file %p",
> >   file->f_op == &shm_file_operations, file);
> 
> And this is totally unexpected from you.
> 		In the name of bug-free kernel,
> 		  I DO WANT KERNEL INTERNALS!
> And I perfectly know which ones at which spots!

You as (or having the ear of) a subsystem maintainer can make that
judgement.  If your marker is more of a low-level field diagnostic
sort of thing, feel free to pass the most appropriate values - even
binary dumps of things.  An end user will not normally attach to those
markers.

> [...]
> And finally, systemtap.

(Thanks for trying it.)

> Reading some systemtap docs,
> http://sourceware.org/systemtap/wiki/UsingMarkers
> where examples of intelligent filtering are shown:
> 
> 	function inode_get_i_ino:long (i:long) %{ /* pure */
> 		struct inode *inode = (struct inode *)(long)THIS->i;
> 		THIS->__retvalue = kread(&(inode->i_ino));
> 		CATCH_DEREF_FAULT();
> 	%}
> 	probe kernel.mark("kfunc_entry")
> 	{
> 		printf("inode number: %d\n", inode_get_i_ino($arg1))
> 	}
> 
> Is this representative example?

I hope not -- this embedded-C stuff should only be necessary if we
need to compensate for the data-stingyness of the marker.  See just
below that on the wiki page for a more generous marker.

> If yes, systemtap only wants marker's name and ignores totally its
> fmt string. So, why add them in the first place?

Actually, systemtap will have consumed the format strings by then
(during script translate time), in order to figure out the types of
$argN.

> And if systemtap can hook at any place, it doesn't need markers (I
> haven't used it though, so correct me).

Systemtap doesn't *need* markers in the sense of it being an essential
prerequisite.  But it is beneficial to have them around, in order to:

- suffer only a small fraction of kprobes dispatching overhead
- pass pretty arbitrary parameters without relying on much compiler
  cooperation, and specifically without requiring debugging info


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