LWN: Comments on "Ktap — yet another kernel tracer"

Loops

bluss — Fri, 31 May 2013 02:46:58 +0000

I looked into the ktap code, it's interesting to see how much of the Lua VM and seeminly its table implementation is there.

So if it's like Lua's tables, then you can delete key-value pairs during iteration fine, but you shouldn't add key-value pairs during iteration; if you do, I think iteration is unpredictable.

I think it's a bit misleading that no notice is given in the license header of the files with copies of lua code (even if lua authors are credited elsewhere). It becomes misleading when the file lists 'Author:' without declaring all of them.

https://github.com/ktap/ktap/blob/master/interpreter/table.c

http://www.lua.org/source/5.2/ltable.c.html

Loops

nix — Mon, 27 May 2013 20:52:28 +0000

As long as the integer iteration and table iteration don't contain a way for the current loop value to be changed during the loop, that should be OK. I wonder what happens if you change a table while iterating over it... you *can* make that have defined, consistent, and always-terminating behaviour (I did it in a C hash table once) but it tends to lead to rather complex iterators which I doubt have been implemented here. (In my case, about 40% of the code of the iterator was to deal with the stable-iteration-over-mutation case.)

Loops

corbet — Thu, 23 May 2013 13:31:45 +0000

From what I can tell, ktap's loops are limited to bounded integer iteration (a Fortran "DO" loop, essentially) or iterating over a table. So, while the execution time could be unacceptably high, everything should terminate.

Ktap — yet another kernel tracer

nix — Thu, 23 May 2013 09:05:27 +0000

I note that, unlike DTrace, the ktap language implements loops, which were intentionally left out of D (the DTrace language) because as soon as your language has loops and conditionals you cannot prove that execution will terminate in the general case without slamming into the halting problem, and that also constrains proof of all sorts of other properties about the code, since an awful lot of them reduce to the halting problem again. The most you can do in a constrained environment like the kernel is to impose a timeout on script execution.

Of course, in a privileged tracer there are lots of other ways to cause trouble inside the kernel, and there is not yet any DTrace port for Linux which implements unprivileged tracing -- but at least unprivileged tracing is implementable there. I don't see how it could be implemented in ktap without a crude timeout or something of that ilk. Nonetheless, ktap looks very interesting and I am cheering from the sidelines, since a bytecode interpreter is much more elegant than the module-compilation approach taken by SystemTap.

(one note: DTrace for Linux is available to everyone, not just paying customers, though you do need to use the UEK2 kernel. The source for the userspace component I work on is not available, though :( )