Date: Wed, 24 Sep 1997 06:45:46 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: kato@migmatite.eps.nagoya-u.ac.jp, current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. Message-ID: <199709240645.XAA06352@usr07.primenet.com> In-Reply-To: <199709240515.WAA20124@implode.root.com> from "David Greenman" at Sep 23, 97 10:15:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> To undo the change in 1.49/1.41.2.1 of /sys/dev/vn/vn.c may hide the > >> panic. But, I think this is NOT real fix. > > > >I made patches for current and 2.2. They are better than undoing. > >Should they be committed? > > What is wrong with using LK_CANRECURSE ? You have to unlock the same number of times as you lock. The flag tells you when to unlock again (which in true recursion would have been done by the caller after the recursive call completed). > In any case, the exact cause of the recursive locking needs to be > understood before this sort of change is made. I think it's OK (except for the bug in the non-current patch; see other message). You may wish to have someone else code-review it, though. I think it's actually a kludge to a kludge, but I don't see a terrifically clean way of doing what needs to be done that caused the problem in the first place. If you could *know* the lock was held, and hold it on subsequent vp's in all cases, that might be a better fix. But there might be a real need for it to be unlocked (I'm thinking multiple accessors racing on simultaneous parent/child directory traversals). Anyway, someone else should definitely look at it to vet. the code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709240645.XAA06352>