Date: 07 Dec 1998 22:28:14 -0500 From: "Robert V. Baron" <rvb@cs.cmu.edu> Cc: freebsd-current@FreeBSD.ORG Subject: Sloppy uio.uio_procp initialization ... Message-ID: <yzs1zmbmhwx.fsf_-_@sicily.odyssey.cs.cmu.edu> In-Reply-To: "Robert V. Baron"'s message of 02 Dec 1998 10:23:01 -0500 References: <4.1.19981123122653.00abfe40@206.25.93.69> <19981125142249.B38959@matti.ee> <yzsogpmk1pm.fsf_-_@sicily.odyssey.cs.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Recently I fixed vnode_pager_input_old, because it was doing a VOP_READ into a Coda fs, but it had set the uio.uio_procp to 0 vs curproc. (Coda freaks because it vgets a vnode [and hence locks it with curproc], then tries to unlock it with a 0 process pointer.) I just noticed (the hard way) the same design happens in ktrwrite(): ktrwrite(vp, kth) struct vnode *vp; register struct ktr_header *kth; { struct uio auio; struct iovec aiov[2]; register struct proc *p = curproc; /* XXX */ int error; ... auio.uio_procp = (struct proc *)0; ... vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); error = VOP_WRITE(vp, &auio, IO_UNIT|IO_APPEND, p->p_ucred); VOP_UNLOCK(vp, 0, p); So here the vn_locks are using the actual process pointer, but since uio_procp is 0, coda will try an unlock not with curproc and fail. I'll change ktrwrite to use auio.uio_procp = curproc, Wed Noon EST, unless anyone objects. PS For the curious, Coda is locking and unlocking a vnode associated with the Coda vnode (which caches the file data) -- not the Coda vnode. 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?yzs1zmbmhwx.fsf_-_>