> > As near as I can tell the panic is happening in VOP_GETATTR(). It looks > > to me like it would be possible for the vnode to be recycled between the > > time when it passes the vp->v_mount test at the top of the loop and the > > time when vn_lock() succeeds. Shouldn't we bump the vnode reference > > count by calling vref() at the top of the loop and add the appropriate > > calls to vrele()? > > Rev.1.395 made some changes that I didn't like much here. The > VOP_GETATTR() is now done unconditionally. This pessimizes vflush() > and enlarges any race windows. I think WRITECLOSE is only used for > mount -u from rw to ro, so the pessimization exercises code that was > rarely used before. > > Rev.1.394 called VOP_GETATTR() with the interlock held. This was wrong > but probably reduced race windows. The window seems to have been > opened before rev.1.394 by releasing mntvnode_slock before aquiring > the interlock. RELENG_4 doesn't release mntvnode_slock at that point > (it holds both locks across the VOP_GETATTR()). > > Bruce > > I have patches that fix the locking behavior in vflush() in my current VFS smp patch. It's not quite complete but it has most of struct vnode locked down. The patch even moves the getattr back into the conditional path. This may fix the behavior here. Again, this is more than vflush, but I didn't want to seperate that out and test it before going to bed. If this fixes the problem I can commit the relavent part of this patch soon. http://www.chesapeake.net/~jroberson/VFSsmp.patch Cheers, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
