I just stumbled across this vnode locking problem in procfs() db> tr Debugger(c05215d4,c0520b94,c669b000,c0521615,e6d77764) at Debugger+0x54 vfs_badlock(c0521615,c0520b94,c669b000,c05b4340,c669b000) at vfs_badlock+0x45 assert_vop_locked(c669b000,c0520b94,c0520adf,358,c6a35400) at assert_vop_locked+ 0x62 vn_fullpath(c66ce390,c669b000,e6d777a8,e6d777ac,c04ea6fb) at vn_fullpath+0xbc procfs_doprocfile(c66ce390,c61c2960,c6272000,e6d777d4,0) at procfs_doprocfile+0x 3a pfs_readlink(e6d77c10,c05210fd,c05b49c0,c6b2e920,e6d77c94) at pfs_readlink+0x116 VOP_READLINK(c6b2e920,e6d77c94,c6911d80,bfbed240,400) at VOP_READLINK+0x59 kern_readlink(c66ce390,bfbed650,0,bfbed240,0) at kern_readlink+0xc1 readlink(c66ce390,e6d77d10,c0535a6a,3fb,3) at readlink+0x38 syscall(2f,2f,2f,8134400,bfbedfd0) at syscall+0x26e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (58, FreeBSD ELF32, readlink), eip = 0x8058a73, esp = 0xbfbed21c, eb p = 0xbfbeda68 --- when I ran find / -print0 | xargs -0 ls -l with the DEBUG_VFS_LOCKS kernel option. The obvious part of the fix is to lock the vnode in procfs_doprocfile() before calling vn_fullpath(). The more interesting question is if this means that all callers of (pn->pn_func)() need to drop their vnode locks in order to prevent a potential deadlock. It looks to me like this is necessary ...Received on Sun Jun 01 2003 - 00:43:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:10 UTC