Freeing vnodes.

[David Schultz]

On Tue, Mar 29, 2005, Jeff Roberson wrote:
> On Tue, 29 Mar 2005, Jeff Roberson wrote:
> 
> > On Mon, 28 Mar 2005, David Schultz wrote:
> >
> > > On Mon, Mar 28, 2005, Jeff Roberson wrote:
> > > > > > I am worried about the v_dd,v_ddid fields of a directory B that has the
> > > > > > to be released vnode A as parent. (Obviously in this case there is no
> > > > > > namecache entry with the vnode A as the directory (nc_dvp))
> > > > > >
> > > > > > Right now A is type stable - but if A is released, access to B->v_dd
> > > > > > may cause a page fault.
> > > > > >
> > > > > > Stephan
> > > > >
> > > > > Jeff,
> > > > >
> > > > > Do you plan to address the problem now that the code is checked in?
> > > >
> > > > Vnodes with children in the name cache are held with vhold() and not
> > > > recycled.
> > >
> > > Yes, but cache_purge() is called directly in a number of places
> > > where the vnode may have children, e.g. in mount.  So dangling
> > > references might still be possible unless cache_purge() fixes up
> > > the children's v_dd pointers appropriately.
> > >
> >
> > ah, indeed.  How does this look:
> 
> Also, are the ids really necessary now that we don't reuse vnodes?
> Shouldn't the pointer be sufficient?

I think so.  The patch I sent you a few days ago gets rid of v_id
except in vfs_cache_lookup(), where it is used to guarantee that
the vnode hasn't changed while sleeping in vn_lock().  With vnode
reclamation, that isn't safe anyway, so if you fix vfs_cache_lookup(),
we can kill v_id completely.

Your patch looks okay at a glance, but shouldn't you be iterating over 
v_cache_src instead of v_cache_dst?