From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20091101184418.GM19125@gradx.cs.jhu.edu> References: <55c52a87f0b8c0ac12a81a150f110b2b@brasstown.quanstro.net> <20091101184418.GM19125@gradx.cs.jhu.edu> Date: Tue, 3 Nov 2009 13:30:27 -0200 Message-ID: From: Iruata Souza To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] dtrace for plan 9 Topicbox-Message-UUID: 966b5d4a-ead5-11e9-9d60-3106f5b1d025 On Sun, Nov 1, 2009 at 4:44 PM, Nathaniel W Filardo wrote: > On Sun, Nov 01, 2009 at 11:58:10AM -0500, erik quanstrom wrote: >> On Sun Nov =C2=A01 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 =C2=A0is 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. =C2=A0It = may of > course change the timing of those events, but that's often less of an iss= ue. > If you don't disable safety (as root, you can, AIUI) DTrace writes only t= o > 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. =C2=A0It 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, mak= ing > it trivially terminating), hooks run in non-preemptable context can safel= y > 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. =C2=A0That's a bug and it's not DTra= ce's > fault. > > All that said, DTrace is not perfect and probably has some corner cases t= hat > may cause trouble. =C2=A0I'm sure the Solaris developers would love to he= ar 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