Re: Problems with vnode locking/unlocking

看板DFBSD_kernel作者時間16年前 (2009/05/27 07:32), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串2/4 (看更多)
:Hi, : :I'm running into quite a lot of trouble with vnode locking and :unlocking, releasing, putting, getting, ... I'm 100% sure I got most if :not all of the vnode locking wrong and I reallly need some help :understanding it. It is still unclear to me what vnops need to do what :with regard to locking/unlocking. : :My current code is here: :http://gitweb.dragonflybsd.org/~alexh/dragonfly.git/tree/9de1a66518d104077521a13d7b13ae958fd79d98:/sys/vfs/devfs : :Right now my concerns are mainly in devfs_vnops.c, where all the :locking/unlocking/... occurs or should occur. : :I'd appreciate some insight/comments/corrections/... on this issue! : :Alex Hornung One thing I noticed is that the devfs_root() code path does not look right. This routine can be called any number of times by the kernel, you don't want to allocate a new root vnode every time! devfs_root()->devfs_allocv()->getnewvnode()-> ... If the root node already has a vnode associated with it you have to ref and vn_lock and return that vnode, not allocate a new vnode. I think you might be overwriting previously acquired vnode pointers in that root node and that will certainly mess things up. -- Another thing I noticed is that you need to remember that when you return a vnode in *vpp, the caller is expected that vnode to be referenced (and possibly also locked), which means you don't release the vnode that you are also returning unless you have extra references (2 or more) and you need to get them down to one reference for the return. So for example the devfs_nsymlink() call is calling devfs_allocvp() but it is also returning the vp in *ap->a_vpp. In the case of devfs_nsymlink() I believe it is expected to return a referenced but NOT locked vnode, so you would unlock it but not dereference it before returning. You will want to check all the VNOPS that return a vnode in *ap->a_vpp for similar issues. In the case if nresolve I believe you are doing it correctly... VOP_NRESOLVE() does not return a vnode (there is no ap->a_vpp), it just expects the namecache entry to be resolved and the cache_setvp() call doesn't inherit any refs or anything so you unlock and release the vnode like you are doing. -Matt Matthew Dillon <dillon@backplane.com>
文章代碼(AID): #1A77lt00 (DFBSD_kernel)
文章代碼(AID): #1A77lt00 (DFBSD_kernel)