From owner-freebsd-dtrace@FreeBSD.ORG Sun Jun 30 19:41:21 2013 Return-Path: Delivered-To: dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A16AAFBC for ; Sun, 30 Jun 2013 19:41:21 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm6-vm1.bullet.mail.gq1.yahoo.com (nm6-vm1.bullet.mail.gq1.yahoo.com [98.136.218.192]) by mx1.freebsd.org (Postfix) with ESMTP id 7787D1992 for ; Sun, 30 Jun 2013 19:41:21 +0000 (UTC) Received: from [98.137.12.58] by nm6.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jun 2013 19:38:03 -0000 Received: from [208.71.42.206] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jun 2013 19:38:03 -0000 Received: from [127.0.0.1] by smtp217.mail.gq1.yahoo.com with NNFMP; 30 Jun 2013 19:38:03 -0000 X-Yahoo-Newman-Id: 15832.32458.bm@smtp217.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SvgY7QcVM1mcHdcCiFCawLgvJJ5VRPPGKTz3dPM24sl9UJz 9SNLmvrVbxZ9G4nMwrp4BVLT6N6iCnZfXfElrvdh_WLdaI4rtymbPvl8_v15 YdUn0cLmQIbitnjAHbd0_oAMagej8LHCwTbDkQTJR50_ajQaRA0BpItI0LWD MXxWqH81MO_gG5nMWI_F6DSY3o7..yAs3zZQQHT9aeA2IcN13H87vyx7TLxW TTZqv61EeDOG.5.PNKTTtu.urg49kUfJT4slCFSEbLGhRAAkJw8lcD8qtHU0 UF7n0E5O14IYUEyxTFs8rh7UnbbdYPe96rnZ51l_OspTK2Xiu2_6YaEo3Xfs D1FicNMw9Lj7mus9oPZSkJU7pf6i7an5COWWEouQ_hi8iyHiKEnPKiNb25y5 WwfjxOGHUKOpyHr81fXWjl8f0JAQeGFYGEWOotsqufM2e_ojQYBTIEuHbnl3 .wk71Izh5zXaCahHAI7A4_BJdPMkgrA7ojIwqUECNSghRrTNu4nn6JJBov4l _DY8RRZgref9s6xe63b06BhhrH9N7xZyQbeMKVQ70k5U9yTbdONquJNqRX5C 57kuj5k.JF0kH3qguD28HO67FNURwbLfuHw39YPKOOXPAmuSNVjVsIxHOIHe KaGBhbUEQlpftIqNsQU0lQyk2pyRFWRKOTCCrqfqe4AVY9nLO6.E7Y44IM4M .IF7eQmerMd5CscjzTqKxiIrANh0Asec2wzUiR0uqLEOXeslM X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp217.mail.gq1.yahoo.com with SMTP; 30 Jun 2013 19:38:00 +0000 UTC Message-ID: <51D08916.4030802@FreeBSD.org> Date: Sun, 30 Jun 2013 14:37:58 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130611 Thunderbird/17.0.6 MIME-Version: 1.0 To: dtrace@FreeBSD.org Subject: [CFT] gcc can cause segfaults in ctfmerge Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 30 Jun 2013 19:41:21 -0000 Hi; I have been following a fix to ctfmerge that was done on NetBSD and is caused by a bug in upstream gcc. The issue is summarized here: https://www.illumos.org/issues/3776 I have a patch for FreeBSD here: http://people.freebsd.org/~pfg/patches/patch-dtrace-gcc.diff The process to get some change into illumos seems to be somewhat complex but the issue is not urgent for us as our base gcc was fixed. The patch will be important once we drop gcc from the base system and start using more frequently the pre-packaged gcc though so some more testing/review on this patch is welcome. regards, Pedro. From owner-freebsd-dtrace@FreeBSD.ORG Wed Jul 3 04:10:31 2013 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 96CA435C for ; Wed, 3 Jul 2013 04:10:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9B11A6E for ; Wed, 3 Jul 2013 04:10:31 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id f4so13176096iea.25 for ; Tue, 02 Jul 2013 21:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=8io6A8aydk8/QaDfk+osFEq5sUjOJI6foM28/DX9uLA=; b=FT0fdH+Eq+hQLVxqiOgrQX7gJAUmb5+jhTW3xzZCgxoyXfq2s+wUug06HwJ2NV0aow WcYb21lq0BDqGHeJdK1ZlQB2f00eYMlni+zd/Uzj/zepi6wldEyc/I1aWqzbJty4a011 EZUNhJt63E2QBt8G4XhtRvqXKjMltI/7k+3LO/LZD6WbewngcsSrF1tkRCeNBs84Sxij xCuurmWpoL+Y5Sxdme2kby7R4pRL8tuaY8LhO9CVtSPWPhHcq80/NeyHCPpZEV9xqpAq 3uOxOBUwFNAKmEK2nDy5aK6JLsXor9DLCNtDrUa6PgIClqZnEoxZRAyNPEpTAO0FsDlm qHeg== X-Received: by 10.42.52.6 with SMTP id h6mr993346icg.5.1372824630926; Tue, 02 Jul 2013 21:10:30 -0700 (PDT) Received: from raichu (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id ri10sm22221607igc.1.2013.07.02.21.10.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 21:10:29 -0700 (PDT) Sender: Mark Johnston Date: Wed, 3 Jul 2013 00:10:23 -0400 From: Mark Johnston To: freebsd-dtrace@freebsd.org Subject: [RFC] reworking FreeBSD's SDT implementation Message-ID: <20130703041023.GA82673@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 04:10:31 -0000 Hello, There are a few problems with the way SDT is currently implemented in FreeBSD. First, the DTrace framework isn't notified when modules are unloaded, so any probes created by these modules are never destroyed (this problem isn't specific to SDT though, FBT probes have the same problem). Second, there is currently nothing preventing one from unloading a module while some of its SDT probes are enabled; doing this will generally cause a panic. Finally, providers are "tied" to modules in the sense that dtrace_unregister() is called on each provider declared in a module when that module is unloaded. This is inflexible - probes already have a "module" field to indicate which module they're defined in, and it would restrict the implementation of, say, a hypothetical GEOM or netgraph provider, which would probably contain some common probes for each GEOM or netgraph module. Plus a panic will occur if a probe from one module is enabled and a second module declaring the provider of the probe is unloaded. I have a patch at [1] which tries to solve all of these problems. It more or less completely reworks FreeBSD's SDT implementation (currently contained in kern/kern_sdt.c and cddl/dev/sdt/sdt.c) and changes a number of things: * It adds a pair of hooks into the kernel linker so that dtrace_module_{loaded,unloaded}() are called when modules are loaded and unloaded. This is what's currently done in Solaris/illumos and it makes it possible to ensure that probes are destroyed when a module is unloaded. This is done by going over all the probes whose module name is that of the module being unloaded and destroying them. Unfortunately there are several SDT providers in FreeBSD that actually (incorrectly) set the module name of their probes; the sctp, nfscl, vfs and linuxlator providers do this. In practice this will turn out to be ok since these providers aren't declared across multiple modules - with my patch, an SDT provider is unregistered when the last module that refers to it is unloaded. * Instead of using SYSINIT/SYSUNINIT to register probes and providers as modules are loaded/unloaded, the SDT macros will append provider/probe data to dedicated linker sets in the module (or the kernel). This allows everything to be done lazily: when sdt.ko is loaded, it can just iterate over all the probe linker sets and created probes as needed. This allows SDT to tie a given probe to a module and makes it possible to solve the second problem described above, since the probe can now keep a pointer to its linker_file_t. * Moves the entire SDT implementation (modulo a stub) into sdt.ko, instead of having sdt.ko interacting with some in-kernel SDT code via a set of callbacks. The new SDT implementation is pretty simple; it maintains a global list of SDT providers, each of which keeps a list of its probes (which are all just elements of some module's SDT probe linker set). It has separate hooks for the kernel linker since it needs to be able to call dtrace_register() when a module is loaded; the DTrace framework doesn't allow provider methods to register new providers. I have some ideas on how to simplify the new SDT implementation even further, but what I have now is working fine for me. * Removes references to mod_lock; our DTrace port defines its own mod_lock which has nothing to do with the kernel linker lock, so it's not doing anything useful. Moreover, by having the kernel linker hook call into DTrace with the linker lock held, I've changed the lock ordering rule: in illumos, code is supposed to acquire the provider lock before mod_lock. I'm also writing a man page for the SDT macros so that there's some guidance on how to create SDT probes and providers. There are also some providers (io and nfscl in particular) that are created manually using the code in kern/dtio_kdtrace.c and nfsclient/nfs_kdtrace.c; if no one has any objections, I'd like to convert those providers to use the SDT macros. This will let us delete a bunch of code and would help reduce confusion, since at the moment it looks like there are multiple ways to create new providers, and it's not really clear which way is "correct." I don't yet have a patch for this though. Does anyone have any comments on or objections to my approach? I don't think the patch is ready to commit yet, but it's working well for me as far as actual functionality is concerned. I'm going to be working on this a bit more over the next several days, and any testing or review would be highly appreciated. :) Thanks! -Mark [1] http://people.freebsd.org/~markj/patches/20130702-sdt-module-info.diff From owner-freebsd-dtrace@FreeBSD.ORG Fri Jul 5 03:25:00 2013 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A10B813 for ; Fri, 5 Jul 2013 03:25:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 13D711DE6 for ; Fri, 5 Jul 2013 03:25:00 +0000 (UTC) Received: by mail-yh0-f49.google.com with SMTP id v1so706386yhn.8 for ; Thu, 04 Jul 2013 20:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=krEmr+CZ5CytMaqRIS8xA+jZULHG+wxHlEebYZQHmdc=; b=g4Jqzt1uFnjAcTKaPspXVTucRj45VInC3Yo2N93WV8/RHdveANz81FoG+vIq+tFWnD XlYFjy5szKJeBqlrdJyQmTYM+T4SM3D0SWo3zbPvqRkaEUSKl9yzi6hYPZ2QY6KdhKfG Hny3rYYXxw5iQtQ8e4aKisOGXEm21h0PCrS0nFQvsbo3SKQc6K54a0HOJQH/o5gUfYFB PAmh7+AfPQ8YAPBq6XkrfnXjwzdGQbTlb9nacspWL0QjipN1ittdQyZpQy7h1Iv+o4EK SbYHM2x1SGisXvIVLe1MWZujLJdETPQcvAe0Prc3NLC7jtn2AbDV0iDgbJFbDz7rENm6 nh3w== X-Received: by 10.236.202.211 with SMTP id d59mr4576528yho.221.1372994699510; Thu, 04 Jul 2013 20:24:59 -0700 (PDT) Received: from charmander ([173.243.41.218]) by mx.google.com with ESMTPSA id o32sm9929979yhi.5.2013.07.04.20.24.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Jul 2013 20:24:58 -0700 (PDT) Sender: Mark Johnston Date: Thu, 4 Jul 2013 23:25:36 -0400 From: Mark Johnston To: freebsd-dtrace@freebsd.org Subject: Re: [RFC] reworking FreeBSD's SDT implementation Message-ID: <20130705032536.GA1570@charmander> References: <20130703041023.GA82673@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130703041023.GA82673@raichu> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.14 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: Fri, 05 Jul 2013 03:25:00 -0000 On Wed, Jul 03, 2013 at 12:10:23AM -0400, Mark Johnston wrote: > Hello, > > There are a few problems with the way SDT is currently implemented in > FreeBSD. First, the DTrace framework isn't notified when modules are > unloaded, so any probes created by these modules are never destroyed > (this problem isn't specific to SDT though, FBT probes have the same > problem). Second, there is currently nothing preventing one from > unloading a module while some of its SDT probes are enabled; doing this > will generally cause a panic. Finally, providers are "tied" to modules > in the sense that dtrace_unregister() is called on each provider > declared in a module when that module is unloaded. This is inflexible - > probes already have a "module" field to indicate which module they're > defined in, and it would restrict the implementation of, say, a > hypothetical GEOM or netgraph provider, which would probably contain > some common probes for each GEOM or netgraph module. Plus a panic will > occur if a probe from one module is enabled and a second module > declaring the provider of the probe is unloaded. > > I have a patch at [1] which tries to solve all of these problems. It > more or less completely reworks FreeBSD's SDT implementation (currently > contained in kern/kern_sdt.c and cddl/dev/sdt/sdt.c) and changes a > number of things: > > [...] > > I'm also writing a man page for the SDT macros so that there's some > guidance on how to create SDT probes and providers. I've copied a draft SDT man page below. Any suggestions/corrections/comments/criticisms are most welcome. I would also like to have man pages for individual providers, but this is a start. :) Thanks, -Mark SDT(9) FreeBSD Kernel Developer's Manual SDT(9) NAME SDT -- a DTrace framework for adding statically-defined tracing probes SYNOPSIS #include SDT_PROVIDER_DECLARE(prov); SDT_PROVIDER_DEFINE(prov); SDT_PROBE_DECLARE(prov, mod, func, name); SDT_PROBE_DEFINE(prov, mod, func, name, sname); SDT_PROBE_DEFINE0(prov, mod, func, name, sname); SDT_PROBE_DEFINE1(prov, mod, func, name, sname, arg0); SDT_PROBE_DEFINE2(prov, mod, func, name, sname, arg0, arg1); SDT_PROBE_DEFINE3(prov, mod, func, name, sname, arg0, arg1, arg2); SDT_PROBE_DEFINE4(prov, mod, func, name, sname, arg0, arg1, arg2, arg3); SDT_PROBE_DEFINE5(prov, mod, func, name, sname, arg0, arg1, arg2, arg3, arg4); SDT_PROBE_DEFINE6(prov, mod, func, name, sname, arg0, arg1, arg2, arg3, arg4, arg5); SDT_PROBE_DEFINE7(prov, mod, func, name, sname, arg0, arg1, arg2, arg3, arg4, arg5, arg6); SDT_PROBE0(prov, mod, func, name); SDT_PROBE1(prov, mod, func, name, arg0); SDT_PROBE2(prov, mod, func, name, arg0, arg1); SDT_PROBE3(prov, mod, func, name, arg0, arg1, arg2); SDT_PROBE4(prov, mod, func, name, arg0, arg1, arg2, arg3); SDT_PROBE5(prov, mod, func, name, arg0, arg1, arg2, arg3, arg4); SDT_PROBE6(prov, mod, func, name, arg0, arg1, arg2, arg3, arg4, arg5); SDT_PROBE7(prov, mod, func, name, arg0, arg1, arg2, arg3, arg4, arg5, arg6); DESCRIPTION The SDT macros allow programmers to define static trace points in kernel code. These trace points are used by the SDT framework to create DTrace probes, allowing the code to be instrumented using dtrace(1). By default, SDT trace points are disabled and have no effect on the sur- rounding code. When a DTrace probe corresponding to a given trace point is enabled, threads that execute the trace point will call a handler and cause the probe to fire. Moreover, trace points can take arguments, mak- ing it possible to pass data to the DTrace framework when an enabled probe fires. Multiple trace points may correspond to a single DTrace probe, allowing programmers to create DTrace probes that correspond to logical system events rather than tying probes to specific code execution paths. For instance, a DTrace probe corresponding to the arrival of an IP packet into the network stack may be defined using two SDT trace points: one for IPv4 packets and one for IPv6 packets. In addition to defining DTrace probes, the SDT macros allow programmers to define new DTrace providers, making it possible to namespace logi- cally-related probes. An example is FreeBSD's sctp provider, which con- tains SDT probes for FreeBSD's sctp(4) implementation. The SDT_PROVIDER_DECLARE() and SDT_PROVIDER_DEFINE() macros are used respectively to declare and define a DTrace provider named prov with the SDT framework. A provider need only be defined once; however, the provider must be declared before defining any SDT probes belonging to that provider. Similarly, the SDT_PROBE_DECLARE() and SDT_PROBE_DEFINE*() macros are used to declare and define DTrace probes using the SDT framework. Once a probe has been defined, trace points for that probe may be added to ker- nel code. DTrace probe identifiers consist of a provider, module, func- tion and name, all of which may be specified in the SDT probe definition. Note that probes should not specify a module name: the module name of a probe is used to determine whether or not it should be destroyed when a kernel module is unloaded. See the BUGS section. Note in particular that probes must not be defined across multiple kernel modules. The SDT_PROBE_DEFINE*() macros also take an extra sname parameter. This is used to allow the creation of probes with names containing the `-' char- acter. Specifically, the name argument should contain the probe name with all dashes converted to underscores, and the sname argument should be the probe name as it will be referenced by D scripts. The SDT_PROBE_DEFINE*() macros also allow programmers to declare the types of the arguments that are passed to probes. This is optional; if the argument types are omitted (through use of the SDT_PROBE_DEFINE() macro), users wishing to make use of the arguments will have to manually cast them to the correct types in their D scripts. It is strongly recom- mended that probe definitions include a declaration of their argument types. The SDT_PROBE*() macros are used to create SDT trace points. They are meant to be added to executable code and can be used to instrument the code in which they are called. EXAMPLES The following probe definition will create a DTrace probe called `icmp::unreach:pkt-receive', which would hypothetically be triggered when the kernel receives an ICMP packet of type Destination Unreachable: SDT_PROVIDER_DECLARE(icmp); SDT_PROBE_DEFINE2(icmp, , unreach, pkt_receive, pkt-receive, "struct mbuf *", "struct icmp *"); This particular probe would take two arguments: a pointer to the mbuf(9) containing the incoming packet, and a pointer to the ICMP header for the packet. Note that the module name of this probe is not specified. Consider a DTrace probe which fires when the network stack receives an IP packet. Such a probe would be defined by multiple tracepoints: SDT_PROBE_DEFINE2(ip, , , receive, receive, "struct mbuf *", "struct ifnet *", "struct ip *", "struct ip6_hdr *"); int ip_input(struct mbuf *m) { struct ip *ip; ... ip = mtod(m, struct ip *); SDT_PROBE4(ip, , , receive, m, m->m_pkthdr.rcvif, ip, NULL); ... } int ip6_input(struct mbuf *m) { struct ip6_hdr *ip6; ... ip6 = mtod(m, struct ip6_hdr *); SDT_PROBE4(ip, , , receive, m, m->m_pkthdr.rcvif, NULL, ip6); ... } In particular, the probe should fire when the kernel receives either an IPv4 packet or an IPv6 packet. SEE ALSO dtrace(1) AUTHORS DTrace and the SDT framework were originally ported to FreeBSD from Solaris by John Birrell . This manual page was written by Mark Johnston . BUGS The SDT macros allow the module name of a probe to be specified as part of a probe definition. However, the DTrace framework uses the module name of probes to determine which probes should be destroyed when a ker- nel module is unloaded, so the module name of a probe should match the name of the module in which its defined. SDT will set the module name properly if it is left unspecified in the probe definition; see the EXAMPLES section. One of the goals of the original SDT implementation (and by extension, of FreeBSD's port) is that inactive SDT probes should have no performance impact. This is unfortunately not the case; SDT trace points will add a small but non-zero amount of latency to the code in which they are defined. A more sophisticated implementation of the probes will help alleviate this problem. FreeBSD 10.0 July 3, 2013 FreeBSD 10.0 From owner-freebsd-dtrace@FreeBSD.ORG Sat Jul 6 12:59:01 2013 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6002EF2B; Sat, 6 Jul 2013 12:59:01 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 3924A1731; Sat, 6 Jul 2013 12:59:00 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:64078 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UvS4p-0002Oz-Vb; Sat, 06 Jul 2013 08:59:00 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [RFC] reworking FreeBSD's SDT implementation From: George Neville-Neil In-Reply-To: <20130705032536.GA1570@charmander> Date: Sat, 6 Jul 2013 08:58:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1BF6D495-5C7E-4FC3-B5A7-BB47C3D2D7F8@freebsd.org> References: <20130703041023.GA82673@raichu> <20130705032536.GA1570@charmander> To: Mark Johnston X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.14 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: Sat, 06 Jul 2013 12:59:01 -0000 On Jul 4, 2013, at 23:25 , Mark Johnston wrote: > On Wed, Jul 03, 2013 at 12:10:23AM -0400, Mark Johnston wrote: >> Hello, >>=20 >> There are a few problems with the way SDT is currently implemented in >> FreeBSD. First, the DTrace framework isn't notified when modules are >> unloaded, so any probes created by these modules are never destroyed >> (this problem isn't specific to SDT though, FBT probes have the same >> problem). Second, there is currently nothing preventing one from >> unloading a module while some of its SDT probes are enabled; doing = this >> will generally cause a panic. Finally, providers are "tied" to = modules >> in the sense that dtrace_unregister() is called on each provider >> declared in a module when that module is unloaded. This is inflexible = - >> probes already have a "module" field to indicate which module they're >> defined in, and it would restrict the implementation of, say, a >> hypothetical GEOM or netgraph provider, which would probably contain >> some common probes for each GEOM or netgraph module. Plus a panic = will >> occur if a probe from one module is enabled and a second module >> declaring the provider of the probe is unloaded. >>=20 >> I have a patch at [1] which tries to solve all of these problems. It >> more or less completely reworks FreeBSD's SDT implementation = (currently >> contained in kern/kern_sdt.c and cddl/dev/sdt/sdt.c) and changes a >> number of things: >>=20 >> [...] >>=20 >> I'm also writing a man page for the SDT macros so that there's some >> guidance on how to create SDT probes and providers. >=20 > I've copied a draft SDT man page below. Any > suggestions/corrections/comments/criticisms are most welcome. >=20 > I would also like to have man pages for individual providers, but this > is a start. :) Hello Mark, Sorry to take to long to reply. I think your approach to SDTs is sound = and we should move forward with that, in particular as you say it brings us closer to = the implementation ideas in Solaris. I will try to test your patch on HEAD today and let = you know if I have any problems with it. In the meantime feel free to test and commit it = on your own, don't wait for me. The man page also looks good. Best, George From owner-freebsd-dtrace@FreeBSD.ORG Sat Jul 6 14:23:10 2013 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B540CCBF; Sat, 6 Jul 2013 14:23:10 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 75E04194F; Sat, 6 Jul 2013 14:23:10 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id dn14so3957211obc.16 for ; Sat, 06 Jul 2013 07:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=BcS8bg1VT8SKjzfd1OfpaCu7tAoLp3tjJOt//iBnK44=; b=QV8dZxtDpruAmhMShMsmLC73bhTKqmhI83tTqkLBPgop+9SnJf66yTbvlSruH5xxc6 ONAArYsIP1jnMSClxDb9FRhmqb7LQSK3FufKL/s6A0bvGg2wR6iQ8oLdEU5xPPHK3QsU h+1pzJhOUaXpN/4M+1mL+x5e8FnNIKI2n5Prw6MT8CChxRbzANXa9btgTiDeJcPrg9tY c/8HSAaHQxBHx5C/Puo06y/yBeO7d+h/x79xW1pnlOXUwWbF6Qt6sOfUZkd5HRqYzNWS H5JQE4kBtZ9bV4rPx+y1SQY7KmSIfGIJkIMskjyKYEXLlprMbBSLAieWF0pIcoLlAfAg rD4w== X-Received: by 10.60.39.193 with SMTP id r1mr15274774oek.40.1373120589984; Sat, 06 Jul 2013 07:23:09 -0700 (PDT) Received: from raichu (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id ps5sm23082581oeb.8.2013.07.06.07.23.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 07:23:09 -0700 (PDT) Sender: Mark Johnston Date: Sat, 6 Jul 2013 10:23:06 -0400 From: Mark Johnston To: George Neville-Neil Subject: Re: [RFC] reworking FreeBSD's SDT implementation Message-ID: <20130706142306.GC4559@raichu> References: <20130703041023.GA82673@raichu> <20130705032536.GA1570@charmander> <1BF6D495-5C7E-4FC3-B5A7-BB47C3D2D7F8@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BF6D495-5C7E-4FC3-B5A7-BB47C3D2D7F8@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.14 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: Sat, 06 Jul 2013 14:23:10 -0000 On Sat, Jul 06, 2013 at 08:58:59AM -0400, George Neville-Neil wrote: > > On Jul 4, 2013, at 23:25 , Mark Johnston wrote: > > > On Wed, Jul 03, 2013 at 12:10:23AM -0400, Mark Johnston wrote: > >> Hello, > >> > >> There are a few problems with the way SDT is currently implemented in > >> FreeBSD. First, the DTrace framework isn't notified when modules are > >> unloaded, so any probes created by these modules are never destroyed > >> (this problem isn't specific to SDT though, FBT probes have the same > >> problem). Second, there is currently nothing preventing one from > >> unloading a module while some of its SDT probes are enabled; doing this > >> will generally cause a panic. Finally, providers are "tied" to modules > >> in the sense that dtrace_unregister() is called on each provider > >> declared in a module when that module is unloaded. This is inflexible - > >> probes already have a "module" field to indicate which module they're > >> defined in, and it would restrict the implementation of, say, a > >> hypothetical GEOM or netgraph provider, which would probably contain > >> some common probes for each GEOM or netgraph module. Plus a panic will > >> occur if a probe from one module is enabled and a second module > >> declaring the provider of the probe is unloaded. > >> > >> I have a patch at [1] which tries to solve all of these problems. It > >> more or less completely reworks FreeBSD's SDT implementation (currently > >> contained in kern/kern_sdt.c and cddl/dev/sdt/sdt.c) and changes a > >> number of things: > >> > >> [...] > >> > >> I'm also writing a man page for the SDT macros so that there's some > >> guidance on how to create SDT probes and providers. > > > > I've copied a draft SDT man page below. Any > > suggestions/corrections/comments/criticisms are most welcome. > > > > I would also like to have man pages for individual providers, but this > > is a start. :) > > Hello Mark, > > Sorry to take to long to reply. I think your approach to SDTs is sound and we should > move forward with that, in particular as you say it brings us closer to the implementation > ideas in Solaris. I will try to test your patch on HEAD today and let you know if I have > any problems with it. In the meantime feel free to test and commit it on your own, > don't wait for me. The man page also looks good. Thanks! I've added an updated patch here: http://people.freebsd.org/~markj/patches/20130706-sdt-module-info.diff There aren't any functional differences, just diff reduction and the man page. Thanks, -Mark