Re: DTrace panic while probing syscall::open (and possibly many others)

On May 21, 2009, at 09:29 PM, Mel Flynn wrote:

> On Thursday 21 May 2009 18:53:56 Thomas Backman wrote:
>> On May 13, 2009, at 03:19 PM, Thomas Backman wrote:
>
> <snip electrons>
>
>>> #11 0xffffffff8123c200 in dtrace_copycheck
>>> (uaddr=18446744071581326184, kaddr=Variable "kaddr" is not  
>>> available.
>>> ) at dtrace_isa.c:527
>
>> In /sys/cddl/dev/dtrace/amd64/dtrace_isa.c:
>> static int
>> dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size)
>> {
>>     printf("in dtrace_copycheck(), pre-ASSERT:\n");
>>     printf("kaddr = %u, kernelbase = %u, size = %d, kaddr+size = %u\n
>> \n",
>>        (unsigned int)kaddr, (unsigned int)kernelbase, (unsigned
>> int)size, (unsigned int)(kaddr+size));
>>     ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr);
>>
>>     if (uaddr + size >= kernelbase || uaddr + size < uaddr) {
>>     ...
>>
>> So, I added two printf statements. What happens? IT BECOMES STABLE.
>
> I'm no kernel hacker, but.. if you apply the patch below, does it  
> still panic?
> Make sure to get rid of the printf() you added.
>
> The theory behind this patch is that kernbase isn't initialized at  
> the time of
> that assert, yet code from printf initializes it.
>
> --- dtrace_isa.c.orig   2009-05-21 21:18:54.000000000 +0200
> +++ dtrace_isa.c        2009-05-21 21:23:40.000000000 +0200
> _at__at_ -40,7 +40,8 _at__at_
> #include <vm/vm_param.h>
> #include <vm/pmap.h>
>
> -extern uintptr_t kernbase;
> +//extern uintptr_t kernbase;
> +static uintptr_t kernbase = KERNBASE;
> uintptr_t kernelbase = (uintptr_t) &kernbase;
>
> #define INKERNEL(va) (((vm_offset_t)(va)) >= USRSTACK && \
Hmmmmm. Nope, still panics with your patch, unfortunately. So I  
reverted to my hack, but that doesn't work anymore, either! I did a  
full buildworld/buildkernel yesterday, WITHOUT csup'ing before, so the  
source should have stayed the same.
Now I get this:

# dtrace -n 'syscall::open:entry { trace(copyinstr(arg0)); }'
dtrace: description 'syscall::open:entry ' matched 1 probe
CPU     ID                    FUNCTION:NAME
   0  38977                       open:entry
              0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f   
0123456789abcdef
          0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00  ................
         10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00  ................
[...snip...]
dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry):  
invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28
dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry):  
invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28
dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry):  
invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28

Same error using opensnoop and/or printing and copying in  
in :::return, so something happened with the kernel (modules):
dtrace: error on enabled probe ID 3 (ID 38978: syscall::open:return):  
invalid address (0xffffff803e9faae0) in action #10 at DIF offset 28
710400         1970 Jan  1 01:00:00     0   1370 5509120    
2                      vnstat\0
718047         1970 Jan  1 01:00:00     0   1370 5509120    
0                      vnstat\0
dtrace: error on enabled probe ID 3 (ID 38978: syscall::open:return):  
invalid address (0xffffff803e9afae0) in action #10 at DIF offset 28
dtrace: error on enabled probe ID 3 (ID 38978: syscall::open:return):  
invalid address (0xffffff803e9afae0) in action #10 at DIF offset 28
742667         1970 Jan  1 01:00:00     0   1370 46927872   2  
�;�����XĻ         vnstat\0
750430         1970 Jan  1 01:00:00     0   1370 46927872   0  
�;�����XĻ         vnstat\0

(If this appears broken, beyond a few characters, that's because it IS  
on my screen as well.)

The address (0xffffff803e9afae0) changes without restarting dtrace,  
but it appears fairly constant.

-----------
Now, after reinstalling the modules and rebooting (rather than  
kldunload dtraceall && make install && kldload dtraceall), it works  
with my ugly hack again. Weird. Since it's all modules, why would it  
not work to unload, recompile and reload?

Regards,
Thomas