Date: Wed, 25 Sep 2002 00:50:29 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/sys lockmgr.h Message-ID: <20020925003055.L97589-100000@mail.chesapeake.net> In-Reply-To: <Pine.NEB.3.96L.1020924230751.29616G-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Sep 2002, Robert Watson wrote: > Crazy man! Most definitely! > > This is all wonderful to see. I'll try to get it integ'd into the MAC > tree later this week and see if it closes the race I've been experiencing > in getnewvnode() or not. I'm really pleased our VFS locking is finally > getting cleaned up. Where do you plan to go from here in terms of future > locking strategy, btw? > Well, I noticed some potential races with the mnt vnode mutex as well as the vnode free list. I'd like to verify the usage of locks that were already in place. Also, I don't totally understand some of the flags and races associated with freeing and recycling vnodes. This all seems needlessly complex. It may make sense once I have reviewed it more thuroughly though. I'd like to get rid of the redundant *_fsync code. These are probably all copies of ufs from different points and are broken in many different ways. In terms of SMP safing vfs, it looks like struct buf needs a mutex. I figured out the lock order, it would be something like: vn lock buf lock vn interlock buf interlock Also, the namecache has to be locked down. This is nontrivial. An early attempt to use a big global lock failed. The mount structure has not been locked down. The vnode/device relationship needs some more looking. There are some mp_fixmes, and some general cleanups that should happen. I'd like to be able to run with DEBUG_VFS_LOCKS enabled all the time. Right now there are still places that break on that. After that, namei() and rename() are broken and unsafe wrt locking. Right now all vfs locks are recursive. I may take advantage of that to simplify the rename code. Then I'd like to get rid of the buf cache, but that's another story all together. In short, there is still much to do. As I have said before, my goal is to have at least the top layer of VFS out from underneath Giant by 5.0. Hopefully, ufs & bufs won't require giant either. Then we might have an entire filesystem IO path that is free from giant! Thanks for the encouragement, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020925003055.L97589-100000>