Date: Fri, 12 Dec 2003 19:37:24 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: freebsd-current@freebsd.org Subject: Re: vn_fullpath: 0xc85e24a0 is not locked but should be Message-ID: <Pine.NEB.3.96L.1031212193509.26485B-100000@fledge.watson.org> In-Reply-To: <20031212184001.C4201-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Dec 2003, Jeff Roberson wrote: > This isn't entirely relevant, but I'd like to point out how happy I am > that it works even this much. When I started fixing up VFS we couldn't > even run init without DEBUG_VFS_LOCKS panicing. It took me a few weeks > of hacking to get the system running anything useful with all of these > assertions. A lot of other people have put significant effort in along > the way as well. I'm very happy to see the progress. Very much agreed -- we've made enourmous progress. And, I have to say, having now done a fair amount of development on the Darwin platform also, I really miss the strength of our lock assertion/debugging pieces (extensive use of lock assertions, WITNESS, lock debugging, etc). I've found debugging similar problems in Darwin to be many times harder than on FreeBSD, so we're on the right track... BTW, if someone wants to actually test the patch I posted, I'll be happy to commit it :-). I'll modify it to include a comment about lock orders, however -- I think procfs will always be something of a lock ordering challenge, however. My understanding is that procfs doesn't rely on vnode locks for internal consistency, so we may well just be able to drop and reclaim the vnode lock for this (and also for the map file). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1031212193509.26485B-100000>