Subject: LOCKT vs. POSIX fcntl(F_GETLK,...)

From: "Kendrick M. Smith" <[email-masked]>
Date: Mon, 5 Feb 2001 17:26:38 -0500 (EST)

Hi all,

The LOCKT operation returns a LOCK4denied structure if a conflicting lock
is found.  This structure contains
  - the owner of the conflicting lock, and
  - the endpoints of the conflicting lock (i.e., offset and range)
However, the POSIX system call for lock testing, fcntl(F_GETLK, ...), must
return (in the case of a conflicting lock)
  - the owner of the conflicting lock,
  - the endpoints of the conflicting lock, and
  - the type of the conflicting lock (i.e., whether a read or write lock)
Consequently, the protocol does not quite allow implementation of the
POSIX semantics for lock testing.  The easiest solution would seem to be
the addition of a "type" field to the definition of 'struct LOCK4denied'.
Is the addition of such a field still possible at this point?  Any other
suggestions?     - Kendrick

---

From: Bill Ricker <[email-masked]>
Date: Mon, 05 Feb 2001 17:24:23 -0800

> Is the addition of such a field still possible at this point?  Any other

I've always wander if following posix semantics makes much sense here.
The protocol makes the lock owner an opaque type. Presumably if the
client id in the lock owner is the same as the client's clientid you
could peek inside and interpret the lock owner id, otherwise it has no
value at all. The client id does not identify the host in any meaningful
way in general to the client either. Seems like a more useful thing that
would be useful is the stateid of the lock holder. The client could
bitch at the server admin that this stateid is holding the lock, and if
the admin agrees to release it, he could run a command given the state
id  to revoke the lock. This seem easier than the user of a client
giving a lock owner and a file handle to clear. But even this does not
translate well to fcntl. Lock ownership is specified by a 32 bit sysid
and 32 bit pid. How do you meaningfully map a 64 bit host id and an
arbitrary length lock owner or a 64 bit stateid id in to an flock
structure?

And while we're on the subject. Why make lockt take a lock owner in the
first place. If I'm interested in checking for locks, I think it
reasonable that I would be interested in acquiring locks, so I should do
an open and get a stateid. Seems like this would be a simpler way to go.
Are there many applications that want to check for the presence of a
lock and then not acquire locks?

In fact why do we need lockt at all. Doesn't a compound request of lock
followed by unlock suffice? Is this operation used so much as (V4
locking isn't blocking) to warrant an optimized procedure call?

-- 
bill

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Mon, 5 Feb 2001 20:47:51 -0500 (EST)

> arbitrary length lock owner or a 64 bit stateid id in to an flock

To set flock->l_pid, our client first looks at the clientid in the
nfs_lockowner4 structure.  If it is the client's own clientid, it can
meaningfully interpret the opaque lockowner name, and determine the pid of
the process corresponding to the lockowner.  If the clientid is not equal
to the client's own clientid, it uses rpciod's pid (so rpciod's pid is
really being used whenever we want to say "the pid of a process running on
another client somewhere").

> lock and then not acquire locks?

POSIX fcntl does permit three locking operations:
    fcntl(F_GETLK, ...) which tests for a lock without acquiring it
    fcntl(F_SETLK, ...) which tests for a lock and acquires it if possible
(non-blocking lock)
    fcntl(F_SETLKW, ...) which performs a blocking lock.
So if an application uses fcntl(F_GETLK, ...) instead of fcntl(F_SETLK,
...), it presumably means that it really does want to test for the lock
without acquiring it.  (although I agree that this will not be a common
operation)

> locking isn't blocking) to warrant an optimized procedure call?

LOCK-LOCKU would work in place of LOCKT (and probably occurs infrequently
enough that the extra operation wouldn't be a performance problem in
practice).  But this still won't let us determine the type of the
conflicting lock, so we can't implement the correct semantics for POSIX
fcntl(F_GETLK,...) this way either.

Kendrick