From owner-freebsd-bugs Sat May 24 07:02:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA26083 for bugs-outgoing; Sat, 24 May 1997 07:02:07 -0700 (PDT) Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26077 for ; Sat, 24 May 1997 07:02:04 -0700 (PDT) Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65]) by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id QAA03963; Sat, 24 May 1997 16:01:57 +0200 (MET DST) Message-Id: <199705241401.QAA03963@pat.idt.unit.no> To: dfr@nlsystems.com Cc: freebsd-bugs@hub.freebsd.org Subject: Re: kern/3581: trap 12 in lockstatus() In-Reply-To: Your message of "Sat, 24 May 1997 08:53:15 +0100 (BST)" References: X-Mailer: Mew version 1.06 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 24 May 1997 16:01:56 +0200 From: Tor Egge Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > There is also the VOP_ISLOCKED race to deal with which, I think, is more > common. I have seen it a couple of times. One solution would be to > change *all* calls to VOP_ISLOCKED to vn_islocked which would check VXLOCK > before calling the filesystem. Another would be to change all VFS' > VOP_ISLOCKED to check VXLOCK. You might need to add an `owner' for VXLOCK. Then vn_islocked could block if VXLOCK is set and the owner is different from the caller. If VXLOCK is set and the owner is the same, the locking operations must just be 'stubs'. Not having an owner makes it much more difficult to avoid both deadlocks and races. You might also need to delay the initialization of the `owner' field until vclean has the lock. I would also like to know why the system was not able to recover from a crash. `fsck -p' in /etc/rc complained about values in super block not agreeing with those in the first alternate, but when running fsck manually, no errors were found. I'll probably do some crash tests in the near future on a spare machine. - Tor Egge