From owner-svn-src-all@FreeBSD.ORG Wed Aug 14 21:06:07 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 87ACBF9B; Wed, 14 Aug 2013 21:06:07 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF44A2726; Wed, 14 Aug 2013 21:06:06 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id i3so8119002vbh.12 for ; Wed, 14 Aug 2013 14:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4ZBJjWItfFa81V8V486u6jQAFJn3Bl/osg4jh1eNPDI=; b=Xf6grCLnXSZQobqPEDFlG+hhoBA+SyhgfWOn7UojT/c+7WAZ3xkiCaOr18Sq+1/sXR lgsKN9yLt7Gxm+ewRLGJQcAExAwCxBHJMGFSzEN9nOLMiIh48fVelcLIi9FBENQBndHa lftifzdkrzVeDVBFgsF6ltZfV9iJdoGrohJ8lN1plFvIQAr7cYVEc2psAO7c3bFghO0a waaOWjnJiJaRMzlzaNEtINsoq7fDl2b9HanouO7tpNE+m3CDJkDgqiKxA8Drd1Pc0h1g uE3wn6NbGyntcXV7RkKRUeIRV82NafLpcVxicuRMYer8h4jdrcjgN56mWkWloJlJDIeW F9rg== MIME-Version: 1.0 X-Received: by 10.220.48.194 with SMTP id s2mr1796305vcf.43.1376514366101; Wed, 14 Aug 2013 14:06:06 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.65.4 with HTTP; Wed, 14 Aug 2013 14:06:06 -0700 (PDT) In-Reply-To: <201308141548.11407.jhb@freebsd.org> References: <201308140042.r7E0gMtf054550@svn.freebsd.org> <201308140819.13854.jhb@freebsd.org> <201308141548.11407.jhb@freebsd.org> Date: Wed, 14 Aug 2013 17:06:06 -0400 X-Google-Sender-Auth: yGRqgJ6RSSIHfUfKAQs5x8REa0Y Message-ID: Subject: Re: svn commit: r254309 - in head: share/man/man9 sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/dev/dtrace sys/cddl/dev/sdt sys/kern sys/sys From: Mark Johnston To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Mark Johnston , src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 21:06:07 -0000 On Wed, Aug 14, 2013 at 3:48 PM, John Baldwin wrote: > On Wednesday, August 14, 2013 2:14:53 pm Mark Johnston wrote: > > On Wed, Aug 14, 2013 at 8:19 AM, John Baldwin wrote: > > > > > On Tuesday, August 13, 2013 8:42:22 pm Mark Johnston wrote: > > > > Author: markj > > > > Date: Wed Aug 14 00:42:21 2013 > > > > New Revision: 254309 > > > > URL: http://svnweb.freebsd.org/changeset/base/254309 > > > > > > > > Log: > > > > Use kld_{load,unload} instead of mod_{load,unload} for the linker > file > > > load > > > > and unload event handlers added in r254266. > > > > > > > > Reported by: jhb > > > > X-MFC with: r254266 > > > > > > Thanks! BTW, it would be really nice to replace HWPMC_HOOKS in > > > kern_linker.c with > > > EVENTHANDLER calls. I think kld_load would just work (though you might > > > need to > > > downgrade the lock before you run it). For kld_unload it seems you > want > > > two events, > > > a kld_unload_try for your newly added event (since it can reject a > > > kld_unload), and > > > perhaps kld_unload at the end where the current HWPMC_HOOK is. Just an > > > idea if > > > someone is looking for something to do. I know there are other modules > > > that need > > > to hook into linker events like this, and making HWPMC_HOOKS more > generic > > > would be > > > a big help. > > > > > > > I will look into doing this. The DTrace SDT kld_load handler will not > work > > properly if the > > linker lock is downgraded first because of the following code in > > linker_file_lookup_set(): > > > > locked = KLD_LOCK(); > > if (!locked) > > KLD_LOCK(); > > > > In particular, it checks to see if the kld lock is exclusively held and > > locks it if not, which > > obviously causes problems if the thread holds the shared lock. > > > > The answer might be to just run the hwpmc handler with the exclusive lock > > held. Or perhaps > > we just need a linker_file_lookup_set_locked(), assuming that it's ok to > > look up a linker set > > with the shared lock held. > > It is probably fine to do a lookup with a shared lock. We could also fix > the > linker code to only lock if there is not an existing shared or exclusive > lock. > Sorry if I'm being dense, but I thought it wasn't generally possible to determine whether curthread holds a given shared lock.