From owner-freebsd-arch Mon Nov 12 15:56:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 05D5337B416 for ; Mon, 12 Nov 2001 15:56:56 -0800 (PST) Received: from fledge.watson.org (ak82hjs7hex92j@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fACNudB37043; Mon, 12 Nov 2001 18:56:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 12 Nov 2001 18:56:38 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: Matthew Dillon , freebsd-arch@FreeBSD.ORG Subject: Re: cur{thread/proc}, or not. In-Reply-To: <3BF05877.B9E886D8@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 12 Nov 2001, Terry Lambert wrote: > Matthew Dillon wrote: > > Yes, I believe this is how credentials work. I looked at > > the code about 6 months ago. We should not have to do any > > locking of the credential stuff, only simple mutexing > > around the ref counter. That is how it should work > > is how I believe it currently works. > > FWIW: > > Robert had implied that more heavyweight locking of the process (or > thread) structure was necessary to access the credential, which is > correct, if you are referencing it that was. In the proposed model, there are two relevant subject credentials: the thread credential, and the process credential. The thread credential is static for the lifetime of the system call, and while the call is on-going, it can be used without any locking/atomic primitives (with the exception of when additional references are added to be cached in objects). The process credential is shared, and, if you will, the 'real' copy. This reference is changed as the process's notion of credential is updated, and requires locks, as it might be changed by multiple threads (potentially in parallel), as well as inspected by other processes for the purposes of reporting (to ps, for example), or for access control (signal delivery, debugging, ...) One of the many nice things about the model, which should be credited to John, is that it doesn't require locking operations in most usage situations. > The part of me you quoted here was a conclusion based on using direct > references to value-stable credentials rather than value-colatile proc > or thread structs. It only works to refute Roberts argument if you > include that; it's not correct to conclude that the way it currently > works is sufficient in the face of the proc/thread dereference issues > that Robert was trying to address (and which I tried to address by > avoiding entirely). ... 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-arch" in the body of the message