Re: [9fans] dtrace for plan 9

[Iruata Souza <iru.muzgo@gmail.com>]

On Sun, Nov 1, 2009 at 4:44 PM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
> On Sun, Nov 01, 2009 at 11:58:10AM -0500, erik quanstrom wrote:
>> On Sun Nov  1 11:55:47 EST 2009, devon.odell@gmail.com wrote:
>> > Also, D is not compiled in kernel. The dtrace utility compiles the D
>> > script, and the script goes through some sanity checking in the D
>> > compiler. The bytecode is sent to the kernel to execute. There are
>> > some in-kernel safety guarantees -- for instance, a D script causing a
>> > nil ptr deref in kernel obviously shouldn't (and does not) cause the
>> > system to panic.
>>
>> that wasn't my main concern.
>>
>> there are many interrupt routines that depend on
>> the exact sequence of events and probing  is likely
>> to wreck havoc.
>
> D is not able (AFAIK, anyway... the design seems like it oughtn't be) to
> change the externally observable sequence of events to hardare.  It may of
> course change the timing of those events, but that's often less of an issue.
> If you don't disable safety (as root, you can, AIUI) DTrace writes only to
> its own logs, even if it can read almost everything.
>
>> how do you prevent probes from reading read-to-clear
>> registers?
>
> DTrace has a notion of "toxic" regions of memory -- lists provided by
> drivers -- which D is not allowed to access.  It is possible to get these
> wrong, and that's a bug, just like it would be possible to get the driver
> itself wrong.
>
>> how do you know a probe in an irq routine won't set
>> off a latent race?
>
> AIUI since D bytecode is loop-free (it permits only forward branches, making
> it trivially terminating), hooks run in non-preemptable context can safely
> inherit non-preemption from their hooked context.
>
> If you've got a race between CPUs that's tickled by DTrace, it could also be
> tickled by changing your compiler, or dynamic CPU clocking, or a higher
> priority IRQ, or ... take your pick.  That's a bug and it's not DTrace's
> fault.
>
> All that said, DTrace is not perfect and probably has some corner cases that
> may cause trouble.  I'm sure the Solaris developers would love to hear from
> you if you find one.
>

if i remember correctly, in 2006 i took Sun's SA-327-S10 course on dtrace.
after learning some D, i tried the obvious thing: enabling all probes.

something strange has happened after that. here i try to reproduce
from memory the steps i took and the strange thing i found (if anyone
is still able to reproduce the thing, i'm curious)

on a solaris 10 system:
1. log in to a CDE session
2. open two ksh terminal windows (w1 and w2 from now on, respectively)
3. type some commands at random in w1
4. type some commands at random in w2
5. with the up arrow key, check the command history on both windows
6. run dtrace enabling all probes in w2 (the system may become slow)
7. interrupt dtrace
8. check the command history of the windows

i was told dtrace was non-intrusive at the time, but w2 would show the
command history from w1.

iru