Date: Thu, 03 Apr 1997 20:10:45 -0800 From: David Greenman <dg@root.com> To: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> Cc: freebsd-hackers@freebsd.org, Tor.Egge@idi.ntnu.no Subject: Re: kern/3184: vnodes are used after they are freed. (dup alloc?) Message-ID: <199704040410.UAA08780@root.com> In-Reply-To: Your message of "Thu, 03 Apr 1997 22:10:40 EST." <199704040310.WAA09093@lakes.water.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704040410.UAA08780>