Date: Tue, 12 Dec 2000 16:21:57 -0800 (PST) From: John Baldwin <jhb@FreeBSD.ORG> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Can !curproc touch Message-ID: <XFMail.001212162157.jhb@FreeBSD.org> In-Reply-To: <Pine.NEB.3.96L.1001212165140.62929F-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12-Dec-00 Robert Watson wrote:
>
> My understanding is that a number of systems perform a crcopy() while
> holding the struct proc mutex, and get an additional ucred reference which
> is then passed down the VFS stack, guarantying that the credentials are
> used consistently. This addresses a number of problems, including the
> multi-threaded case where you want a system call to be processed entirely
> under one set of credentials, serializing requests from the perspective of
> the credential. The general rule for reference counts should be that the
> holder of the reference count is responsible for protecting it: if the
> owner of the reference is struct proc, then the user of that reference
> must protect struct proc while using the reference. If the use of the
> reference is relatively long-term, then an additional reference should be
> created and used instead (i.e., crref()), allowing the user to release the
> protection (mutex, lock, invariants, whatever) on the struct proc. This
> was the type of reference count race condition I was discussing, btw, at
> BSDCon while we were futzing around at the whiteboard discussing drivers
> and related stuff.
Well, currently nothing uses the struct proc mutex when touching p_ucred. This
is some code from coda:
/*
* find root of cfs
*/
int
coda_root(vfsp, vpp)
struct mount *vfsp;
struct vnode **vpp;
{
struct coda_mntinfo *mi = vftomi(vfsp);
struct vnode **result;
int error;
struct proc *p = curproc; /* XXX - bnoble */
...
error = venus_root(vftomi(vfsp), p->p_ucred, p, &VFid);
To fix this I could do this:
struct ucred *uc;
...
PROC_LOCK(p);
uc = p->p_ucred;
crhold(uc);
PROC_UNLOCK(p);
error = venus_root(...., uc, ...);
crfree(uc);
In place of the last line. However, note that p is always curproc. If all the
other places that accees p->p_ucred only do so if p == curproc, then I don't
need to use an explicit lock to protect p_ucred, as it will be implicitly
locked. Thus, my question is is there a place where a process A can read or
write the p_ucred of process B. If there is, then I need to use the proc mutex
to protect p_ucred. If not, I can leave p_ucred alone.
--
John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
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?XFMail.001212162157.jhb>