[DTrace][FreeBSD 6.1] Should a kernel global variable reference land up for validation in dtrace_canstore?

[Shrikanth Kamath]

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?

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