Date: Tue, 22 Jun 2010 23:15:52 +0530 From: Shrikanth Kamath <shrikanth07@gmail.com> To: freebsd-hackers@freebsd.org Subject: [DTrace][FreeBSD 6.1] Should a kernel global variable reference land up for validation in dtrace_canstore? Message-ID: <AANLkTimZ85vzArfCk2Dt2iokeFYG_ldjYKNsQIqGIkne@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimZ85vzArfCk2Dt2iokeFYG_ldjYKNsQIqGIkne>