From owner-freebsd-current Tue Sep 23 23:46:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA07551 for current-outgoing; Tue, 23 Sep 1997 23:46:23 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA07545 for ; Tue, 23 Sep 1997 23:46:19 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id XAA06352; Tue, 23 Sep 1997 23:45:46 -0700 (MST) From: Terry Lambert Message-Id: <199709240645.XAA06352@usr07.primenet.com> Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. To: dg@root.com Date: Wed, 24 Sep 1997 06:45:46 +0000 (GMT) Cc: kato@migmatite.eps.nagoya-u.ac.jp, current@FreeBSD.ORG In-Reply-To: <199709240515.WAA20124@implode.root.com> from "David Greenman" at Sep 23, 97 10:15:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> 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.