From owner-freebsd-dtrace@freebsd.org Wed Oct 31 18:47:45 2018 Return-Path: Delivered-To: freebsd-dtrace@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86EBB10E1DA6 for ; Wed, 31 Oct 2018 18:47:45 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B34B83262 for ; Wed, 31 Oct 2018 18:47:45 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd41.google.com with SMTP id a5-v6so1563324ioq.8 for ; Wed, 31 Oct 2018 11:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=balDIYtAsyNHZjMNLC2LrT35c+BTesmjMwuN4sUg5Xw=; b=q6XA+JPx2smmZwDe98LUxiDqqDpWlwhvs8O6Vo7z4J+FP88YegCzeSXsnB5Vnb1rgu VySB2s+euNgoQ/qK74IRwMRGQcRgcEbAkYkeMQhcX8ygkVVq7M8/KKuTdn5JzIKDUyOx kiRniPesEk/L7xbz7nEb6bmCx7he/Si7d4SPoQ+5ORi0P6xkZHYatmNyJPm679RkF0pe 3fJNhQkq1ApkeiUIagH4Bya0TgG1KQ0AwACaVNgZxg0HDR7+7kvcdgROcjRO+e4b/KuP mta/HbdY7gUjveThHMKdyMUzmuJ+X92xiF5DhMvhN6myziegusj0JBc/b2RJ67qhMNcw 445w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=balDIYtAsyNHZjMNLC2LrT35c+BTesmjMwuN4sUg5Xw=; b=qNlUBTtsJGoAW6yMMShe6GzeS1yw331BkYlaM+KR6y0nxvyVnXOC0TlrW/GZcIr9wd rl0q25qAP++1aGrsVvxV1g81QvRurra8QW1zkHz9Cbf3nPQOffPS/4eOy6T69RwxHa42 ism5yRQo16ML5/2Xmg8K+UCWCG8jfnlJZuO4Id1/x5YaQLq5NamPuOrnG/7iQTtX/Veu ldJUpO3UYW6EC/xCTPuYlX1mSdDOZg+NfUiDqulM3LTb8QNd7JfA6k6g0sUr1xjQDFp1 Wua0XmfcjwJ3q3yy7NlRhLGMh91bQ1GjMIpVncavhOtjmSnXj+IwsNzjGtdmBXOFrYQE azXg== X-Gm-Message-State: AGRZ1gISbPwC5SY1zLJWeKdhR6gDeAuY+tT5sw9G0t/tzSRgC21UkhcB 6Tiwf/d4VgtDgffi9vijUqk= X-Google-Smtp-Source: AJdET5cRCbmqlBOWhLA25ljRZZq7Wo4sXgV6lwemHVnjMESLPz1tqMY+hzxOt01zSpE28ZuEPmy3vQ== X-Received: by 2002:a6b:f818:: with SMTP id o24-v6mr3114844ioh.203.1541011664341; Wed, 31 Oct 2018 11:47:44 -0700 (PDT) Received: from spy (toroon0812w-lp140-01-64-229-12-188.dsl.bell.ca. [64.229.12.188]) by smtp.gmail.com with ESMTPSA id m1-v6sm8974413iob.15.2018.10.31.11.47.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 31 Oct 2018 11:47:43 -0700 (PDT) Sender: Mark Johnston Date: Wed, 31 Oct 2018 14:46:43 -0400 From: Mark Johnston To: Andreas Longwitz Cc: "freebsd-dtrace@freebsd.org" Subject: Re: Why my DTrace script does not work after installing a new kernel without reboot Message-ID: <20181031184643.GA1686@spy> References: <5BD4E965.9040006@incore.de> <20181027225339.GA4191@spy> <5BD9F001.9090603@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BD9F001.9090603@incore.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 18:47:45 -0000 On Wed, Oct 31, 2018 at 07:10:09PM +0100, Andreas Longwitz wrote: > In the meantime I found the answer to my question. > > > Does your patch change the layout of the timeout structure? If so, the > > problem is that dtrace(1) is using the CTF from kern.bootfile, but that > > doesn't match the layout of the structures used by the running kernel. > > dtrace() gets the CTF of the kernel and kernel modules from the > pathbames returned by kldstat(2). In my case they all start with > '/boot/kernel/' because the kernel was loaded from that place. This can > be veryfied with 'kldstat -v'. The output does not change after buildung > a new kernel and the kernel itself does nit use the variable > kern.bootfile. I see, thanks for digging into it. I suspect that the real solution is to ensure that CTF files are mapped into the kernel's address space when an object is loaded, and provide an interface for userland to fetch CTF files for the running kernel. We've talked about doing this before, but I'm a bit unhappy about the extra memory consumption; the compressed CTF file for the kernel's file alone on my laptop is slightly under 1MB in size. Maybe that's not worth worrying about. Note that the same bug exists today in the kernel: link_elf_ctf_get() fetches a CTF file using the path cached in the KLD structure, i.e., the path exported by kldstat -v. At present, the kernel only uses CTF to fill out type info when creating FBT probes, so it's not a major problem.