Date: Tue, 24 Apr 2001 10:10:56 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: smp@FreeBSD.org Subject: RE: sysctl's and mutexes Message-ID: <XFMail.010424101056.jhb@FreeBSD.org> In-Reply-To: <Pine.NEB.3.96L.1010423222248.5746C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010424101056.jhb>