Date: Fri, 22 May 2009 09:31:44 +0200 From: Thomas Backman <serenity@exscape.org> To: Mel Flynn <mel.flynn+fbsd.current@mailing.thruhere.net> Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) Message-ID: <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> In-Reply-To: <200905212129.47892.mel.flynn%2Bfbsd.current@mailing.thruhere.net> References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn%2Bfbsd.current@mailing.thruhere.net>
index | next in thread | previous in thread | raw e-mail
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
> @@ -40,7 +40,8 @@
> #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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44F486FA-E798-448D-BE31-F7A51EF1F612>