linux-kernel - Re: [PATCH 5/5] tracing/ftrace: Introduce the big kernel lock tracer

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]

Message-ID: <20081024192949.GC8210@redhat.com>
Date:	Fri, 24 Oct 2008 15:29:49 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Frédéric Weisbecker <fweisbec@...il.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, systemtap@...rces.redhat.com
Subject: Re: [PATCH 5/5] tracing/ftrace: Introduce the big kernel lock tracer

Hi -

On Fri, Oct 24, 2008 at 05:26:53PM +0200, Frédéric Weisbecker wrote:
> [...]
> Actually what I thought is a style like this (Python like):
> 
> probe = Systemtap.probeFunc("lock_kernel")
> probe.captureUtime("utime"))
> probe.captureBacktrace("trace")
> probe.trace()
> 
> For an obvious set of batch work like that, that could be possible,
> perhaps even easy to implement an Api...
> When the object calls trace(), the userspace Systemtap analyse the list
> of work to do and then translate into commands in kernel space.

There comes a point not too far beyond this example where one may want
to capture functions of values; filter; perform loops/conditionals;
refer to variables/arrays.  Coding that logic this way would be so
clumsy as to take away any charm of working in python.


> And the script could wait for events and then do its own processing
> with the captured events (do some operations on delays, on output....).
> 
> for event in probe.getEvent(): #blocking
>     print event["utime"]
>     trace = event["trace"] #Systemtap.trace object with specific
> fields and a default string repr
>     print trace
> 
> It would be interpreted by Python itself [...]

This is too gets impractical.  If the only event handler code is
general python, it can't practically be executed within the kernel.
So we're then talking about a python script consuming trace data
streamed in.  We lose:
- capability to take immediate action upon event occurrence
- any claim to good performance (~microsecond event handling)
- the natural coupling between events and their handlers
- the ability to statically analyze the entire instrumentation,
  to optimize locking, data encoding


Now, one may imagine using this sort of thing as a *wrapper* around
plain systemtap: where the python libraries generate stylized
systemtap code that emits data in a form that the later "getEvent"
routine can decode again and act upon.

Several people have written shell, perl, even awk scripts scripts to
generate systemtap code for particular special purposes.  So one can
hide the script language as an implementation detail of a higher level
tool.  It's not a substitute though.


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