From owner-freebsd-arch Tue Dec 12 16:22:52 2000 From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 16:22:49 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 338BD37B400; Tue, 12 Dec 2000 16:22:48 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBD0MhE03982; Tue, 12 Dec 2000 16:22:43 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eBD0Lvl21462; Tue, 12 Dec 2000 16:21:57 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 12 Dec 2000 16:21:57 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Robert Watson Subject: Re: Can !curproc touch Cc: arch@FreeBSD.ORG Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 -- 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