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_-_>