Date: Thu, 28 Feb 2002 13:39:08 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: smp@FreeBSD.org Subject: Re: Some thoughts on Giant instrumentation Message-ID: <Pine.NEB.3.96L.1020228133307.70229E-100000@fledge.watson.org> In-Reply-To: <XFMail.020228100951.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm not opposed to the idea of instrumentation, although that's probably simply that so far we haven't managed to shoot ourselves quite enough to have me wish I had it. One of my concerns with instrumentation has always been the fine-grained issue: throwing Giant back into the mix will change a fair amount about the codepath, and that if we adopt a phased locking of a large structure (proc, for example), then we don't have all that much granularity, suggesting that we'll probably want to look at something that has more complexity than the current scheme. One of my particular concerns has been regarding the following: suppose a structure is covered by three or four relevant locks. We decide to selectively instrument one of those sets of locks (perhaps because we just added it, having determined the others are stable). do we want to be able to say: s = giant_instrument(PROCLOCK_INST | PGRPLOCK_INST | ALLPROC_INST); Where the test can check to see if any of the particular instrumented bits of the mask require Giant, and then DTRT? This would help somewhat with the "collapse the instrumentation" some, assuming the simplification that we don't do too much instrumentation below the system call where it gets complex. Which appears to be something we should avoid doing anyway so that Giant doesn't end up in the wrong place in the lock order. It's probably worth mentioning that instrumentation of this sort has actually been very useful in the TrustedBSD code with regards to enforcement. We can selectively turn off enforcement of MAC policies along two axies: first, we can disable specific policies, and second, we can disable the impact of enforcement across particular types of enforcement. For example, there are sysctls to enable/disable enforcement for inter-process operations, filesystem operations, network operations, socket operations, etc. Likewise, we can turn off enforcement for MLS, Biba, TE, and so on, independently. They are also loader tunables so that you can stick things in loader.conf to recover a machine that's very hosed, or turn things on later when getting past special cases in the boot, or to test a particular system call. 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.1020228133307.70229E-100000>