Date: Tue, 31 Oct 1995 10:55:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davidg@root.com Cc: terry@lambert.org, current@freebsd.org Subject: Re: *MORE* FS problems, please fix! Message-ID: <199510311755.KAA10220@phaeton.artisoft.com> In-Reply-To: <199510311421.GAA09530@corbin.Root.COM> from "David Greenman" at Oct 31, 95 06:21:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510311755.KAA10220>