From owner-freebsd-hackers Thu Apr 3 20:09:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA13138 for hackers-outgoing; Thu, 3 Apr 1997 20:09:54 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA13133 for ; Thu, 3 Apr 1997 20:09:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id UAA08780; Thu, 3 Apr 1997 20:10:45 -0800 (PST) Message-Id: <199704040410.UAA08780@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Thomas David Rivers cc: freebsd-hackers@freebsd.org, Tor.Egge@idi.ntnu.no Subject: Re: kern/3184: vnodes are used after they are freed. (dup alloc?) In-reply-to: Your message of "Thu, 03 Apr 1997 22:10:40 EST." <199704040310.WAA09093@lakes.water.net> From: David Greenman Reply-To: dg@root.com Date: Thu, 03 Apr 1997 20:10:45 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You know, your mailer does absolutely disgusting things to the To: and cc: lines of messages. I either have to delete the stuff or rewrite it to something RFC 822 compliant. This last message would have tried to send replies to ucbvax.berkeley.edu...a machine which doesn't even exist anymore. >Wow! > > I was _very_ excited by this report; especially since it seemed >to match the 'dup alloc' panic I've reported, and it was a timing >issue, and this is certainly the area where I get "dup alloc"s and >"free vnode isn't" panics... > > So, I applied the following diff to a 2.1.7 tree, which basically >moves the call to VOP_INACTIVE() until after the vnode has been >added to the free list (as Tor had described) [Tor - does this seem >to be what you intended? The source in 2.1.7, of course, doesn't >have the SMP locking, etc....]: > >*** vfs_subr.c.ori Thu Aug 15 13:08:20 1996 >--- vfs_subr.c Thu Apr 3 20:07:46 1997 >*************** >*** 835,840 **** >--- 835,843 ---- > panic("vrele: ref cnt"); > } > #endif >+ >+ VOP_INACTIVE(vp); >+ > if (vp->v_flag & VAGE) { > TAILQ_INSERT_HEAD(&vnode_free_list, vp, v_freelist); > vp->v_flag &= ~VAGE; >*************** >*** 843,849 **** > } > freevnodes++; > >- VOP_INACTIVE(vp); > } > > /* >--- 846,851 ---- Uh, this is wrong since VOP_INACTIVE really wants a '0' usecount vnode, and there are assumptions throughout the code that a '0' usecount also implies that the vnode is on the free list. A quick code review of Tor's suggested fix shows that it will fail in several places in the kernel and basically needs to be re-thought...which is why it hasn't been committed yet. >Unfortunately, I am still able to demonstrate my particular problem :-( Not a surpise to me, actually. You problem appears not to have anything to do with vnodes...it appears to be a buffer problem (or FFS allocation bug) of some kind. >So, I'm beginning to wonder... is there a way a vnode can get >onto the freelist; but still be "busy" somehow... Of hand, >is there a way to check for this condition I could add to the code >to see if that's what's going on? No, a vnode on the free list is always "free" - it will be removed from the free list prior to any I/O occuring. The only caveat to this is that entries in the namei cache can point to "free" vnodes and there is some kludgewear to deal with this. There is already code in the kernel to check for "free vnode isn't" conditions where a vnode usecount is non-zero while the vnode is on the free list...but I'm not aware of any bugs related to this in the current code. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project