vn_fullpath: 0xc85e24a0 is not locked but should be

[Robert Watson]

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 at fledge.watson.org      Senior Research Scientist, McAfee Research