Date: Sat, 24 May 1997 16:01:56 +0200 From: Tor Egge <Tor.Egge@idi.ntnu.no> To: dfr@nlsystems.com Cc: freebsd-bugs@hub.freebsd.org Subject: Re: kern/3581: trap 12 in lockstatus() Message-ID: <199705241401.QAA03963@pat.idt.unit.no> In-Reply-To: Your message of "Sat, 24 May 1997 08:53:15 %2B0100 (BST)" References: <Pine.BSF.3.95q.970524085117.331F-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705241401.QAA03963>