Date: Tue, 8 Dec 1998 16:13:28 +1100 From: Bruce Evans <bde@zeta.org.au> To: rvb@cs.cmu.edu Cc: freebsd-current@FreeBSD.ORG Subject: Re: Sloppy uio.uio_procp initialization ... Message-ID: <199812080513.QAA16116@godzilla.zeta.org.au>
next 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(): NetBSD doesn't pass a process pointer to the locking functions. When I looked at this in connection with some problems in quotaoff(), I deciced that NetBSD is correct, for the following reason: unlocking should only be done by the same process that holds the lock, except possibly during process exit and system shutdown, since unlocking another process' locks won't actually work while that process is still alive. Unlocking on behalf of another process during process exit and system shutdown apparently isn't needed (except probably when we shoot ourself in the foot by doing sync(&proc0, NULL) in boot() even in the non-panic case). Therefore, the process to use for unlocking is always given by curproc, and there is no need to waste time passing it to unlocking functions, and no way to use wrong values for it taken from uio.uio_procp. Bruce 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?199812080513.QAA16116>