From owner-freebsd-current Tue Oct 31 10:07:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA13388 for current-outgoing; Tue, 31 Oct 1995 10:07:07 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA13294 for ; Tue, 31 Oct 1995 10:06:52 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA10220; Tue, 31 Oct 1995 10:55:22 -0700 From: Terry Lambert Message-Id: <199510311755.KAA10220@phaeton.artisoft.com> Subject: Re: *MORE* FS problems, please fix! To: davidg@root.com Date: Tue, 31 Oct 1995 10:55:21 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: <199510311421.GAA09530@corbin.Root.COM> from "David Greenman" at Oct 31, 95 06:21:27 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3002 Sender: owner-current@freebsd.org Precedence: bulk > > The locking subsystem is *incorrectly* implementing locking via a > > call to vn_* from the file system specific lock code. > > > > > > The design says that the FS specific lock code is, in fact, advisory. > > Advisory locks *are* advisory. The advisory locking is implemented via > VOP_ADVLOCK() in the appropriate system calls. Is this another case where > you completely misunderstand, at the most fundamental level, how the code > works? If you're looking at VOP_LOCK/VOP_UNLOCK and thinking that these have > something to do with file locking, look again, they don't. You are missing the distinction between "advisory locking" and "locking implementation is advisory in nature". The first is a given. The second, which is what I was talking about, is that the file locks implemented by ufs_lock/ufs_unlock and the advisory range locks that are implemented in ufs_advlock by calling lf_advlock are to be implemented using an assert/veto mechanism (and they are currently *not* implemented this way). Basically, in kern/vfs_syscalls and kern/kern_descrip.c: call underlying fs lock/unlock/getlock Needs to be changed to: switch(ap->a_op) { case F_SETLK: do lf_setlock if success call underlying fs lock if fail back out lf_setlock endif endif case F_UNLCK: verify existance using lf_getlock if exists call underlying fs unlock if success /* can not fail because of verification!*/ do lf_clearlock endif endif case F_GETLK: get lock using lf_getlock #ifdef REMOTE_RELEASE_ALLOWED get lock using underlying fs getlock if not_same force local coherency endif #endif /* REMOTE_RELEASE_ALLOWED*/ } The point being that for most of the "underlying fs's", the VOP_LOCK, VOP_UNLOCK, and VOP_ADVLOCK calls should always simply return success, unstead of relying on code that is potentially shared with other OS's (like Linux and SunOS) to implement locking using the same primitives. The underlying fs, though, does have the right to veto a lock, and though NFS does not support remote release coherency, some other FS or distributed computing environment might. Finally, the locks themselves should be hung off the vnode rather than the in core portion of the inode. This resolves the code duplication and coherency issues in asserting locking semantics uniformly across multiple disparate FS's. Tell me, does file and advisory locking work correctly in msdosfs, cd9660fs, ext2fs, etc.? It would if it used the same code even before the fs is called. Say we want to add support for mandatory locking because we want to run Xenix binaries. Should the support need to be added on a case by case basis to all underlying file systems? The answer, according to the Heidemann thesis, is "no". The same is true of the existing file and advisory locking implementation. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.