[comp.sys.sun] record locking with fcntl

tmm33@leah.albany.edu (Terry McCoy) (10/08/90)

I have written a function that uses fcntl to lock a segment of a file.
The function works when the file is located on the local filesystem.  But
when I attemp to use this function to perform locking on a file that is
located on a NFS mounted filesystem the program will crash with a panic
within the kernel "Memory address alignment".  I did use the F_RSETLK
command when trying to lock the file on the NFS filesystem as opposed to
F_SETLK on the file that was on a local filesystem.  Any ideas why the
lock on the NFS filesystem will cause the panic and the lock on the local
filesystem does not.

Terry McCoy
internet:    tmm33@leah.albany.edu

guy@uunet.uu.net (Guy Harris) (10/27/90)

>I did use the F_RSETLK command when trying to lock the file on the
>NFS filesystem as opposed to F_SETLK on the file that was on a
>local filesystem.

DON'T DO THAT!

To quote from the manual page for FCNTL(2V) in SunOS 4.1:

     F_RSETLK
     F_RSETLKW
     F_RGETLK       Are  used  by  the   network   lock   daemon,
                    lockd(8C), to communicate with the NFS server
                    kernel to handle locks on the NFS files.

Those are *INTERNAL INTERFACES* intended to be used *ONLY* by the lock
daemon.  They are NOT supposed to be used by any other programs.  In order
to lock a file on a remote machine, you're supposed to use the *EXACT
SAME* F_SETLK/F_SETLKW/F_GETLK calls that you use for files on the local
machine; the NFS client code on your machine will communicate with the
lock manager on the server and it will end up doing F_RSETLK calls *for*
you on *that* machine.

There is no guarantee that the F_RSETLK/F_RSETLKW/F_RGETLK calls take
arguments that, in any way, shape, or form, resemble the arguments to
F_SETLK/F_SETLKW/F_GETLK.  In fact, if they don't, this may explain why
your program is blowing up.  (There's still a bug in the SunOS kernel if
it panics; it should require a process that does the
F_RSETLK/F_RSETLKW/F_RGETLK calls to be super-user, or to have registered
itself as the lock daemon, or in some other way identify itself as having
the right to issue those calls, or alternatively should properly check the
arguments to that call and reject any that aren't valid.)