Date: Tue, 29 Mar 2005 08:56:32 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: David Schultz <das@freebsd.org> Cc: Stephan Uphoff <ups@tree.com> Subject: Re: Freeing vnodes. Message-ID: <20050329085512.M54623@mail.chesapeake.net> In-Reply-To: <20050329030011.I54623@mail.chesapeake.net> References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <1110896909.29804.39143.camel@palm> <1111983665.64310.19.camel@palm> <20050329071006.GA10416@VARK.MIT.EDU> <20050329030011.I54623@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Mar 2005, Jeff Roberson wrote: > On Tue, 29 Mar 2005, David Schultz wrote: > > > 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. > > You're right, cache_lookup() needs to be changed to return a referenced > vnode. There are only a few callers outside of vfs_cache.c that I'll have > to change. I'll put this on my todo list. After that v_id can go away. > I'll look at your patch again soon. I fixed this. You should wrap vn_fullpath() with Giant and then commit your patch. I'll do the VFS_LOCK_GIANT() bit. Do you think we can get rid of v_id and v_ddid after you commit your patch? > > > > > Your patch looks okay at a glance, but shouldn't you be iterating over > > v_cache_src instead of v_cache_dst? > > > > Yes, I thought I double checked that. I haven't done any name cache stuff > in a while, and I always get confused whether src means sources for this > vnode, or names this vnode is a source for. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050329085512.M54623>