Date: Mon, 23 Apr 2001 22:31:50 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: smp@FreeBSD.org Subject: sysctl's and mutexes Message-ID: <Pine.NEB.3.96L.1010423222248.5746C-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
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;
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");
This is a poor example, but you get the picture. Such a change would
allow us to retain the simple declaration of sysctl's that are effectively
statically compiled variables being exported to userland, while adapting
to the fine-grained kernel code. This came up in particular for the
jailNG code, where each jail instantiated introduces a fair number of
sysctl's, all of which are expected to be accessed while holding the
per-jail mutex, which is known when the sysctl is dynamically added.
I may be off-base here, but it's just a thought. :-)
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
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?Pine.NEB.3.96L.1010423222248.5746C-100000>