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

Powered by blists - more mailing lists