From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 17:23:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6351065673; Fri, 19 Jun 2009 17:23:34 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF1A8FC15; Fri, 19 Jun 2009 17:23:34 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 181432C2A81; Fri, 19 Jun 2009 12:02:02 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NhDYNKWf7e3b; Fri, 19 Jun 2009 12:01:54 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 2564A2C2A7E; Fri, 19 Jun 2009 12:01:54 -0500 (CDT) Message-ID: <4A3BC481.1010600@cs.rice.edu> Date: Fri, 19 Jun 2009 12:01:53 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Andriy Gapon References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.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> <4A3A1D27.4010802@icyb.net.ua> <4A3BBF5A.6060702@icyb.net.ua> In-Reply-To: <4A3BBF5A.6060702@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , John Birrell , freebsd-current@freebsd.org, Thomas Backman Subject: Re: DTrace panic while probing syscall::open (and possibly many others) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 17:23:34 -0000 Andriy Gapon wrote: > 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)) > > Yes. Your analysis is correct. Alan