From owner-freebsd-smp Tue Apr 24 10:11:47 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 04CAA37B423; Tue, 24 Apr 2001 10:11:45 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3OHBZG67714; Tue, 24 Apr 2001 10:11:35 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 24 Apr 2001 10:10:56 -0700 (PDT) From: John Baldwin To: Robert Watson Subject: RE: sysctl's and mutexes Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 24-Apr-01 Robert Watson wrote: > > Right now, there are effectively two types of data sysctl's: ones where > sysctl understands (to some extent) the semantics of what is being > handled/stored (int, string, fixed-size opaque), and ones where it doesn't > (user-provided handler). As the kernel becomes increasingly fine-grained, > many if not all of the values tweakable using sysctl will need to have > some sort of synchronization primitive that protects their consistency and > validity. Right now, to implement acquisition of appropriate > synchronization for any writable (and many readable if it is desirable to > read values set frequently within the kernel) sysctl's, it is necessary to > write a handler for each and every sysctl, which essentially consists of a > wrapper in the form of: > > mtx_lock(&this_sysctls_mutex); > > ... > > mtx_unlock(&this_sysctls_mutex); > > Perhaps in some cases an appropriate sxlock. This seems like a bit of a > waste, in that it requires almost all sysctl's to move from being normal > well-defined types to being handlers, etc. I've been considering what > would be involved in allowing an additional flag/field that would > indicating to the sysctl system that an appropriate mutex would need to be > acquired when performing operations on the node in question. For example: > > mtx_t jail_set_hostname_allowed_mtx; s/mtx_t/struct mtx/ :-P > int jail_set_hostname_allowed = 1; > SYSCTL_INT(_jail, OID_AUTO, set_hostname_allowed, CTLFLAG_RW|CTLFLAG_MTX, > &jail_set_hostname_allowed, &jail_set_hostname_allowed_mtx, 0, > "Processes in jail can set their hostnames"); It might very well be desirable to add a new parameter for each sysctl that is a pointer to a mutex. However, an appropriate SYSINIT() or some such during startup needs to initialize that mutex before that sysctl is used. If need be, we can also add a flag to determine if the sysctl should initialize the mutex itself or not. Ideally then, we would create a new SYSINIT on the fly to initialize the mutex in question. I think though, that requiring explicit initialization of each mutex shouldn't be too hard. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message