From owner-freebsd-arch Mon Nov 12 14:54:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id EF6BA37B416; Mon, 12 Nov 2001 14:54:31 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fACMsNd06845; Mon, 12 Nov 2001 14:54:23 -0800 (PST) (envelope-from dillon) Date: Mon, 12 Nov 2001 14:54:23 -0800 (PST) From: Matthew Dillon Message-Id: <200111122254.fACMsNd06845@apollo.backplane.com> To: Terry Lambert Cc: Robert Watson , freebsd-arch@FreeBSD.ORG Subject: Re: cur{thread/proc}, or not. References: <3BF05241.74F895EF@mindspring.com> 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 :The point is that if the credentials are granted, then a :change in credential is not a change of the credential itself, :but is instead a copy-on-write proposition. In other words, :credentials, once granted, are priviledge stable. : :If this is the case, then they are written when they are :instanced, cloned before they are modified (indeed, it seems :that the clone/modify operation must be made atomic), and :thus are never written once instanced -- only destroyed on :the 1->0 reference transition. : :If so, then no locking is required, since the LCK CMPXCHG can :be utilized to do atomic increment and decrement on the :reference counting, without needing locks. :... : :-- Terry 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message