linux-kernel - Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

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:	Fri, 15 Sep 2006 16:49:21 -0700
From:	Nicholas Miell <nmiell@...cast.net>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Roman Zippel <zippel@...ux-m68k.org>,
	Thomas Gleixner <tglx@...utronix.de>, karim@...rsys.com,
	Andrew Morton <akpm@...l.org>,
	Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

On Sat, 2006-09-16 at 01:14 +0200, Ingo Molnar wrote:
> * Roman Zippel <zippel@...ux-m68k.org> wrote:
> 
> > > > This is simply not true, at the source level you can remove a static 
> > > > tracepoint as easily as a dynamic tracepoint, the effect of the 
> > > > missing trace information is the same either way.
> > > 
> > > this is not true. I gave you one example already a few mails ago (which 
> > > you did not reply to, neither did you reply the previous time when i 
> > > first mentioned this - perhaps you missed it in the high volume of 
> > > emails):
> > > 
> > > " i outlined one such specific "removal of static tracepoint" example 
> > >   already: static trace points at the head/prologue of functions (half 
> > >   of the existing tracepoints are such). The sock_sendmsg() example i 
> > >   quoted before is such a case. Those trace points can be replaced with 
> > >   a simple GCC function attribute, which would cause a 5-byte (or 
> > >   whatever necessary) NOP to be inserted at the function prologue. The 
> > >   attribute would be alot less invasive than an explicit tracepoint (and 
> > >   thus easier to maintain) "
> > 
> > As I said before you're mixing up function tracing with event tracing, 
> > not all events are tied to functions, functions can be moved and 
> > renamed, the actual event more often stays the same.
> 
> you are showing a clear misunderstanding of how tracing is typically 
> done. Both for LTT and for blktrace (and for the tracers i've done 
> myself), roughly half (50%) of the tracepoints are right at the top of 
> the function and trace the function arguments. Let me quote an example 
> straight from LTT:
> 
>  int sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
>  {
>          struct kiocb iocb;
>          struct sock_iocb siocb;
>          int ret;
> 
>          trace_socket_sendmsg(sock, sock->sk->sk_family,
>                  sock->sk->sk_type,
>                  sock->sk->sk_protocol,
>                  size);
> 
> this tracepoint, under a dynamic tracing concept, can be replaced with:
> 
>  int __trace sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
>  {
>          struct kiocb iocb;
>          struct sock_iocb siocb;
>          int ret;
> 
> note the "__trace" attribute to the function. (see my previous mails 
> where i talked about __trace for more details) SystemTap can hook to 
> that point and can access the very same parameters that the markup does, 
> in a lot less invasive way.
> 
> So a 5-line markup can be replaced with a single function attribute.
> 
> roughly half of the existing tracepoints in blktrace/LTT can be replaced 
> that way. A 50% reduction in the number of markups is significant - but 
> such a reduction in markups not possible under the static tracing 
> concept. And that method was just off the top of my head - Andrew 
> provided other ideas to reduce the number of markups.
> 

You're going to want to be able to trace every function in the kernel,
which means they'd all need a __trace -- and in that case, a
-fpad-functions-for-tracing gcc option would make more sense then
per-function attributes.

The option could also insert NOPs before RETs, not just before the
prologue so that function returns are equally easy to trace. (It might
also inhibit tail calls, assuming being able to trace all function
returns is more important than that optimization.)


And SystemTap can already hook into sock_sendmsg() (or any other
function) and examine it's arguments -- all of this GCC extension talk
is just performance enhancement.

-- 
Nicholas Miell <nmiell@...cast.net>

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