Date: Tue, 12 Dec 2000 19:48:54 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: John Baldwin <jhb@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Can !curproc touch Message-ID: <Pine.NEB.3.96L.1001212194545.62929G-100000@fledge.watson.org> In-Reply-To: <XFMail.001212162157.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Dec 2000, John Baldwin 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: ... > 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. Whenever a process acts on another process and inter-process authorization is required, p_target->p_ucred will be dereferenced. p_ucred is also dereferenced for process information services, such as sysctl() as used by ps and other process-grubbing programs. See p_can*(), sysctl_out_proc(), procfs, et al. I'm not sure there's ever a write case, but there are many read cases by this definition. 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.1001212194545.62929G-100000>