[1477] in NetBSD-Development
Problem with NetBSD AFS clients and flock(2)
daemon@ATHENA.MIT.EDU (Brian Buhrow)
Tue Oct 7 14:21:53 1997
From: buhrow@cats.ucsc.edu (Brian Buhrow)
Date: Tue, 7 Oct 1997 11:19:45 +0000
To: netbsd-afs@MIT.EDU
Cc: buhrow@cats.ucsc.edu
hello folks. I've been researching this problem for some time and
think I see a problem with the NetBSD port of AFS 3.3 with regard to
flock(2).
There are two problems. First, whenever flock(fd, LOCK_UN) is called
against a file in AFS space, the caller is given an EINVAL error condition
on return from the call. Second, whenever one tries to release a shared
lock, type LockRead in AFS parlents, the lock is never released, meaning
no one else, including the currently running application, can get a write
lock on the file until the lock is physically broken.
I believe these two problems stem from the same source. Specifically,
in afs/afs/_nbsdops.c in the afs33 source tree with the NetBSD diffs
applied, the flock call eventually winds its way down to a call to
afs_lockctl (afs_nbsdops.c:1023) with whatever command argument the
sys_flock() call pased to it. In the case of LOCK_UN, the command argument
in ap->a_op is F_UNLCK. It appears that afs_lockctl doesn't recognize this
command and returns EINVAL. I'm still a little confused as to why
releasing an exclusive lock would work even though the EINVAL is still
returned. Perhaps it really isn't working either and I'm still learning my
way through the AFS debugging process.
It looks like the way to fix this problem is to call afs_lockctl()
with a F_SETLK op code and then to make the type of lock to be set an
F_UNLCK. Alternatively, we could check for an acmd of F_UNLCK if we're in
the AFS_NETBSD_ENV and release the lock that way.
Any thoughts/previous fixes for this problem? (I'm using with
NetBSD/i386 1.2G (9/2/97 sources)
-thanks
-Brian
