From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 10:36:26 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C67316A428 for ; Fri, 22 Jul 2005 10:36:26 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8996443D7F for ; Fri, 22 Jul 2005 10:35:30 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 07AC146B81; Fri, 22 Jul 2005 06:35:30 -0400 (EDT) Date: Fri, 22 Jul 2005 11:36:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Luigi Rizzo In-Reply-To: <20050722032819.G95489@xorpc.icir.org> Message-ID: <20050722113157.H16902@fledge.watson.org> References: <20050722032819.G95489@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: which lock protects sysctl instances ? 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, 22 Jul 2005 10:36:26 -0000 On Fri, 22 Jul 2005, Luigi Rizzo wrote: > is there any protection in RELENG_5 and above for multiple sysctl > handlers ? > > In other words, assume i have SYSCTL_PROC(_kern, OID_AUTO, foo, > CTLTYPE_STRING|CTLFLAG_RW, > 0, 0, sysctl_foo_handler, "A", "bla bla bla"); > > do i have to worry about multiple instances of sysctl_foo_handler() > running in parallel, or they run under Giant, or some other lock ? Right now, all sysctl handlers are run with Giant. In addition to giant, there are sleep locks in sysctl to protect the sysctl infrastructure. Any further synchronization has to be done by the handler itself. So, for example, you'll see that the process-related handlers all acquire the necessary process locks to operate successfully; likewise network monitoring sysctls, and so on. Right now many sysctl handlers assume that Giant will be held on entry; this is an assumption that we should be reducing or gradually removing. As a general rule, if your sysctl handler interacts with an MPSAFE part of the system, it will need to acquire locks anyway, because those parts of the system well be running in another thread on another CPU but without Giant, so unimpeded. I think we need someone to pick up sysctl again as an owner and start to fix this up -- it's not pressing since it's hardly a performance-critical path for most systems, but it's an area where cleanliness is a good thing. Robert N M Watson