Date: Wed, 20 Mar 2002 08:00:17 -0800 (PST) From: Robert Watson <rwatson@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 8060 for review Message-ID: <200203201600.g2KG0HA89125@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://people.freebsd.org/~peter/p4db/chv.cgi?CH=8060 Change 8060 by rwatson@rwatson_tislabs on 2002/03/20 07:59:18 At some point, the "Process Credentials" section became named "Credentials". Re-alphabetize. Affected files ... ... //depot/projects/smpng/sys/design/article.sgml#20 edit Differences ... ==== //depot/projects/smpng/sys/design/article.sgml#20 (text+ko) ==== @@ -23,7 +23,7 @@ </author> </authorgroup> - <pubdate>$SMPng: //depot/projects/smpng/sys/design/article.sgml#19 $</pubdate> + <pubdate>$SMPng: //depot/projects/smpng/sys/design/article.sgml#20 $</pubdate> <copyright> <year>2002</year> @@ -462,6 +462,39 @@ <title>Specific Locking Strategies</title> <sect2> + <title>Credentials</title> + + <para><structname>struct ucred</structname> is the system + internal credential structure, and is generally used as the + basis for process-driven access control. BSD-derived systems + use a "copy-on-write" model for credential data: multiple + references may exist for a credential structure, and when a + change needs to be made, the structure is duplicated, + modified, and then the reference replaced. Due to wide-spread + caching of the credential to implement access control on open, + this results in substantial memory savings. With a move to + fine-grained SMP, this model also saves substantially on + locking operations by requiring that modification only occur + on an unshared credential, avoiding the need for explicit + synchronization when consuming a known-shared + credential.</para> + + <para>Credential structures with a single reference are + considered mutable; shared credential structures must not be + modified or a race condition is risked. A mutex, + <structfield>cr_mtxp</structfield> protects the reference + count of the <structname>struct ucred</structname> so as to + maintain consistency. Any use of the structure requires a + valid reference for the duration of the use, or the structure + may be released out from under the illegitimate + consumer.</para> + + <para>The <structname>struct ucred</structname> mutex is a leaf + mutex, and for performance reasons, is implemented via a mutex + pool.</para> + </sect2> + + <sect2> <title>File Descriptors and File Descriptor Tables</title> <para>...</para> @@ -576,39 +609,6 @@ since these locks are most likely not going to be used outside of <filename>kern/subr_taskqueue.c</filename>.</para> </sect2> - - <sect2> - <title>Credentials</title> - - <para><structname>struct ucred</structname> is the system - internal credential structure, and is generally used as the - basis for process-driven access control. BSD-derived systems - use a "copy-on-write" model for credential data: multiple - references may exist for a credential structure, and when a - change needs to be made, the structure is duplicated, - modified, and then the reference replaced. Due to wide-spread - caching of the credential to implement access control on open, - this results in substantial memory savings. With a move to - fine-grained SMP, this model also saves substantially on - locking operations by requiring that modification only occur - on an unshared credential, avoiding the need for explicit - synchronization when consuming a known-shared - credential.</para> - - <para>Credential structures with a single reference are - considered mutable; shared credential structures must not be - modified or a race condition is risked. A mutex, - <structfield>cr_mtxp</structfield> protects the reference - count of the <structname>struct ucred</structname> so as to - maintain consistency. Any use of the structure requires a - valid reference for the duration of the use, or the structure - may be released out from under the illegitimate - consumer.</para> - - <para>The <structname>struct ucred</structname> mutex is a leaf - mutex, and for performance reasons, is implemented via a mutex - pool.</para> - </sect2> </sect1> <sect1> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203201600.g2KG0HA89125>