From owner-freebsd-current Mon Feb 11 19: 8:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 5080037B49C for ; Mon, 11 Feb 2002 18:17:15 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 88B2C2323C; Mon, 11 Feb 2002 21:16:52 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id A12CD9F2B6; Mon, 11 Feb 2002 21:11:57 -0500 (EST) Date: Thu, 07 Feb 2002 23:03:31 -0500 (EST) From: John Baldwin To: Terry Lambert Subject: Re: ucred for threads Cc: current@freebsd.org, Julian Elischer Message-Id: <20020212021157.A12CD9F2B6@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08-Feb-02 Terry Lambert wrote: > Since the reference count is positive in both cases, an > unlocked pointer comparison is fine. In the case where > there is a race on a credential change in the unlocked > value, that race exists in the calling code, anyway. The > failure case in a change for->to instead of to->from is > also safe, since the pointers will be inequal during the > update, the lock will be held during the update, so the > subsequent release and regrab with the increment never > dropping below 1. No, an unlocked compare is _not_ ok. What if the p_ucred pointer was changed on some other processor by another thread from this processor? Without a lock you don't have a guarantee that that other processor's writes are visible to you. We really don't want to be using stale credentials for syscalls given the past history of race conditions involving credentials. If in the future it is deemed that getting a stale cred is an acceptable race, then this can be optimized then, but for now we had better get it right. FreeBSD doesn't run on just the i386 anymore, we have Alpha, ia64, and sparc64 SMP machines to deal with as well. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message