Date: Thu, 07 Feb 2002 23:03:31 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: current@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: ucred for threads Message-ID: <20020212021157.A12CD9F2B6@okeeffe.bestweb.net>
next in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020212021157.A12CD9F2B6>