Date: Wed, 4 Apr 2001 13:19:25 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matt Dillon <dillon@earth.backplane.com> Cc: Alfred Perlstein <bright@wintelcom.net>, Brian Somers <brian@Awfulhak.org>, freebsd-arch@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <Pine.NEB.3.96L.1010404131609.14983B-100000@fledge.watson.org> In-Reply-To: <200104041653.f34GrX188215@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Apr 2001, Matt Dillon wrote: > :For those interested in giving the p->p_ucred version a try, the simply > :patch is below. It works between FreeBSD boxes, and my tests against > :Solaris 5.5. Unfortunately, my remote NFS test box already has interop > :problems with Linux due to the new mount_nfs that I haven't applied > :patches to yet, so I can't test that case. > > It occurs to me that we may have a general problem with p->p_ucred > here. For KSEs to work, processes will not be able to assume that > they 'own' p->p_ucred if/when they block. What happens if one thread > is blocked in a system call that is using p->p_ucred directly without > bumping its ref count and another thread goes in and changes the cred? It's fine for now pre-KSE. In some threaded operating systems, the way they handle this is to do a crcopy() of the credential when making potentially long (vis blocking) calls, freezing the credential at the time the call is instantiated. I believe Solaris does this, but haven't checked in a while. So when you make a VFSOP, you crcopy and pass the reference to the copy in so that you can release the locking on the ucred pointer rather than holding the mutex and potentially sleep. This has nicer security properties too--you don't want credentials being inconsistent during a call, our you can introduce nasty races. What this does mean is we probably need an explicit credential passed into the VFS operations, as I suggested as another possible solution to the current crget() problem. However, we can always wait on that until KSE actually starts happening (i.e., solve credential/proc locking problem first, then go apply solution). 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010404131609.14983B-100000>