Date: Wed, 19 Apr 2000 03:49:08 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Dave Chapeskie <dchapes@borderware.com> Cc: Adrian Chadd <adrian@FreeBSD.ORG>, Matthew Dillon <dillon@apollo.backplane.com>, freebsd-fs@FreeBSD.ORG Subject: Re: vnode_free_list corruption Message-ID: <20000419034906.I71428@ewok.creative.net.au> In-Reply-To: <00Apr18.141542edt.117123@gateway.borderware.com>; from Dave Chapeskie on Tue, Apr 18, 2000 at 02:18:24PM -0400 References: <00Apr14.141908edt.117140@gateway.borderware.com> <20000415023148.F34852@ewok.creative.net.au> <200004141835.LAA71253@apollo.backplane.com> <20000418042733.I59015@ewok.creative.net.au> <00Apr17.185117edt.117127@gateway.borderware.com> <20000418174608.C71428@ewok.creative.net.au> <00Apr18.141542edt.117123@gateway.borderware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 18, 2000, Dave Chapeskie wrote: > On Tue, Apr 18, 2000 at 05:46:11PM +0800, Adrian Chadd wrote: > > Yes, but from my take of the code, if a vnode reaches VDOOMED, its been > > earmarked for recycling and is in the process of being flushed. If > > the vnode is being used in the FS code somewhere (or anywhere for that > > matter :) it shouldn't ever be considered for recycling as it should be > > vref()'ed or at the least vhold()'ed. > > I see it the other way around, getnewvnode is perfectly within it's > rights to call vgonel() on a VOP_LOCKED vnode from what I can see (see > code comment below). I think the problem is that vhold and vbusy need > to be checking for VXLOCK and returning an error just the way vget does. > If that's the case it seems silly to have both vhold and vget. Hrm. When will you have a vnone which is VOP_LOCKED but not ref'ed or held? > The vclean() call (from vgonel called by getnewvnode) must be blocking. > It's the only place between getnewvnode()'s setting VDOOMED and it's > later clearing of the flags (assuming VXLOCK isn't already set) where it > can block. There is a comment in vclean() which says: > > /* > * Even if the count is zero, the VOP_INACTIVE routine may still > * have the object locked while it cleans it out. The VOP_LOCK > * ensures that the VOP_INACTIVE routine is done with its work. > * For active vnodes, it ensures that no other activity can > * occur while the underlying object is being cleaned out. > */ > VOP_LOCK(vp, LK_DRAIN | LK_INTERLOCK, p); > > Alternatively it may sometimes be blocking in the vinvalbuf() call. I've re-read the code *again* and I can see the code taking the vnode through being made inactive to possibly going to UFS_TRUNCATE and eventually end up at a vhold.But, the panics you've been throwing here on the list indicate a vnode being used in one process in some fs operation but having no refcount or holdcnt, and its then targeted for VDOOMED. Then the first process ends up at vbusy(), and things go strange from there. THIS is what sounds wrong, don't you agree? What you are saying is that getnewvnode is perfectly right to call vgonel() on a locked vnode if its not used or held. What I'm saying is tht its not right for getnewvnode() to recycle a vnode that is in the middle of some file op, which is what you've indicated as happening (I still can't reproduce the bug, if someone else out there can PLEASE tell me how :) People with vnode clue, please comment. I'm going to spend tomorrow looking at if and why the first is happening. I'll look at the patches you gave tomorrow. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000419034906.I71428>