From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sun,  1 Nov 2009 13:44:18 -0500
From: Nathaniel W Filardo <nwf@cs.jhu.edu>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20091101184418.GM19125@gradx.cs.jhu.edu>
References: <<9ab217670911010852h46cc32a0k2e3ef99323287595@mail.gmail.com>>
	<55c52a87f0b8c0ac12a81a150f110b2b@brasstown.quanstro.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="iKKZt69u2Wx/rspf"
Content-Disposition: inline
In-Reply-To: <55c52a87f0b8c0ac12a81a150f110b2b@brasstown.quanstro.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [9fans] dtrace for plan 9
Topicbox-Message-UUID: 953fe274-ead5-11e9-9d60-3106f5b1d025


--iKKZt69u2Wx/rspf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> that wasn't my main concern.
>=20
> 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.
=20
> 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.

--nwf;

--iKKZt69u2Wx/rspf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrt1wIACgkQTeQabvr9Tc+WiQCfXhlMCag9zRq20O32JbK/ych4
6q4An09ZFn9vxaBPZ+yfXgvyRCh2wt/R
=ioc4
-----END PGP SIGNATURE-----

--iKKZt69u2Wx/rspf--