Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Jun 2009 19:39:54 +0300
From:      Andriy Gapon <avg@icyb.net.ua>
To:        Thomas Backman <serenity@exscape.org>
Cc:        Alan Cox <alc@FreeBSD.org>, freebsd-current@FreeBSD.org, John Birrell <jb@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org>
Subject:   Re: DTrace panic while probing syscall::open (and possibly many  others)
Message-ID:  <4A3BBF5A.6060702@icyb.net.ua>
In-Reply-To: <DD13EADF-CE41-465A-8D70-53DCDEFD65A7@exscape.org>
References:  <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org>	<0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org>	<200905212129.47892.mel.flynn%2Bfbsd.current@mailing.thruhere.net>	<44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org>	<60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org>	<20090522200306.GE2630@atarininja.org>	<20090617225849.GB28509@atarininja.org> <B2F32C8F-810B-4EA5-9E34-39ADD5E5CED4@exscape.org> <4A3A1D27.4010802@icyb.net.ua> <DD13EADF-CE41-465A-8D70-53DCDEFD65A7@exscape.org>

next in thread | previous in thread | raw e-mail | index | archive | help
on 18/06/2009 14:42 Thomas Backman said the following:
> 
> On Jun 18, 2009, at 12:55 PM, Andriy Gapon wrote:
> 
>> on 18/06/2009 12:43 Thomas Backman said the following:
>>>
>>>    at dtrace_isa.c:527
>>> #14 0xffffffff816b31fc in dtrace_copyinstr (uaddr=34365163021,
>>>    kaddr=18446743524025463312, size=256, flags=0xffffffff8146e0c0)
>>>    at dtrace_isa.c:558
>>
>> kaddr=18446743524025463312 == FFFFFF8004467210
>> I think kernelbase on amd64 is 0xFFFFFFFF80000000.
>> FFFFFF8004467210 kaddr
>> is smaller than
>> FFFFFFFF80000000 kernelbase
>>
>> The numbers do look suspiciously similar, so I am not sure if you are
>> seeing a
>> race or a real bug somewhere.
>> -- 
>> Andriy Gapon
> Hmmm...
> Looking around a bit for these numbers, I found, in
> /sys/amd64/include/vmparam.h:
> 
> /*
>  * Virtual addresses of things.  Derived from the page directory and
>  * page table indexes from pmap.h for precision.
>  *
>  * 0x0000000000000000 - 0x00007fffffffffff   user map
>  * 0x0000800000000000 - 0xffff7fffffffffff   does not exist (hole)
>  * 0xffff800000000000 - 0xffff804020100fff   recursive page table (512GB
> slot)
>  * 0xffff804020101000 - 0xfffffeffffffffff   unused
>  * 0xffffff0000000000 - 0xffffff7fffffffff   512GB direct map mappings
>  * 0xffffff8000000000 - 0xffffffffffffffff   512GB kernel map
>  *
>  * Within the kernel map:
>  *
>  * 0xffffffff80000000                        KERNBASE
>  */
> 
> So, kaddr is inside the "kernel map", but not KERNBASE. What this means,
> I have no clue whatsoever. (I'm not a kernel developer and I don't know
> too much about (virtual) memory either!)

Thomas,

I think that you were correct that one needs to be somewhat of a VM expert here.
It seems that amd64 is the only[?] platform where KERNBASE !=
VM_MIN_KERNEL_ADDRESS (0xffffffff80000000 and 0xffffff8000000000 correspondingly).
That makes the assert in sys/cddl/dev/dtrace/amd64/dtrace_isa.c bogus in my opinion:
static int
dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size)
{
        ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr);

If the purpose of the assert is to ensure that [kaddr:kaddr+size) is within kernel
memory, then it should use VM_MIN_KERNEL_ADDRESS instead of KERNBASE. Or maybe
even use something like the macro in sys/amd64/include/stack.h:
#define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < DMAP_MAX_ADDRESS) \
            || ((va) >= VM_MIN_KERNEL_ADDRESS && (va) < VM_MAX_KERNEL_ADDRESS))

The above is just my understanding, not a fact, so I am CC-ing people that are
really knowledgeable of our VM and the porter/author of our DTrace code too.

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A3BBF5A.6060702>