dtrace discuss - Aug 2006 - One more question about probe args

I meant to ask this in my previous post: sorry.

Also, I am assuming that the reason that an "arg" for a
syscall:::entry
has to be in real memory, is that since the ECB runs with interrupts 
disabled, the probe clause isn''t allowed to wait around for the I/O to 
complete to page-in the data.

Correct??

Thanks again,
Chip

Hey Chip,

On Mon, Aug 14, 2006 at 01:24:51PM -0500, Chip Bennett
wrote:
> I meant to ask this in my previous post: sorry.
> 
> Also, I am assuming that the reason that an "arg" for a
syscall:::entry
> has to be in real memory, is that since the ECB runs with interrupts 
> disabled, the probe clause isn''t allowed to wait around for the
I/O to
> complete to page-in the data.
Yes, that''s right.  And it''s not just local I/O -- a page
could be mapped in
over NFS, so you might need to go over the wire to satisfy the fault.
Not that it''s any difference:  in probe context, we cannot block -- at
all,
ever, for any reason.  (Indeed, we can''t even call back into the kernel
at-large, let alone be descheduled.)

This is obviously undesirable (and we''ve come up with some wild ideas
to
deal with this transparently in the common case of the syscall provider) but
it''s (unfortunately) endemic to an arbitrary-context instrumentation
framework...

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc