Discussion:
[DTrace]Should kernel global variable reference land up in dtrace_canstore?
Shrikanth R K
2010-06-22 17:52:09 UTC
Permalink
Although this is in a FreeBSD 6.1 env, I wanted to get some basic question clarified...

I have the following simple DTrace script

% cat fbt_test.d
BEGIN
{
trace(kernel`my_kern_variable);
}

When I run the script I get the following error
dtrace: error on enabled probe ID 1 (ID 1: dtrace:::BEGIN): invalid kernel access in action #1 at DIF offset 4

This is a FreeBSD 6.1 base (I am attempting to get DTrace to work in a FreeBSD 6.1 cross compiler env)

On limited debugging...
I see this 'dtrace_dif_emulate' sets the CPU_DTRACE_KPRIV error...
case DIF_OP_RLDX:
if (!dtrace_canstore(regs[r1], 8, mstate, vstate)) {
*flags |= CPU_DTRACE_KPRIV;
*illval = regs[r1];

I tried figuring out the semantics of "dtrace_canstore", looks like it checks if the asked variable resides anywhere
in the DTrace 'scratch base' or in the space of thread local variables.

My query is since I marked the variable in the script with a back quote should it not consider it as a external reference? The function dtrace_canstore should it run validation on such a reference...

I have inlined the following lines from my debugging session

(kgdb) info address my_kern_variable
Symbol "my_kern_variable" is static storage at address 0xc0bd68ec.

(kgdb) up
#3 0xc5018967 in dtrace_dif_emulate (difo=0xc5bf38c0, mstate=0xee972b00, vstate=0xc4f59c1c, state=0xc4f59c00)

(kgdb) p /x regs[1]
$165 = 0xc0bd68ec <== Same as my_kern_variable, and this gets passed to dtrace_canstore as shown above

(kgdb) p /x mstate->dtms_scratch_base <== Starting at 0xc6a52010 which is greater than the global my_kern_variable
$166 = 0xc6a52010
(kgdb) p /x mstate->dtms_scratch_size
$167 = 0xbffff0

(kgdb) p /x vstate->dtvs_dynvars.dtds_base <== Thread locals base, 0xc7652000 which is also greater than my_kern_variable
$169 = 0xc7652000
(kgdb) p /x vstate->dtvs_dynvars.dtds_size
$170 = 0x100000

If we look at the implementation of "dtrace_canstore" it looks very obvious to fail...with the above parameters.

In a dumb way, what I am trying to figure out is whether to a reference to a kernel global which is external to the dtrace memory areas land up for validation in dtrace_canstore?
Any pointers where to look, how to debug further?

--
Shrikanth R K
--
This message posted from opensolaris.org
Loading...