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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 6 Feb 2001 08:50:56 -0800

Bill Ricker wrote:
> "Kendrick M. Smith" wrote:
> > 
> > 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

> 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.

Right.  I'm assuming that the only thing the client can do with the 
clientid id is see if it is its own.  This is an issue for me because
the conflicting lock may not have an associated clientid.  The conflicting
lock my be held by a CIFS client or an NLM client.  In those cases, I
return a clientid of zero, whcih I never assign to v4 clients.  I'm
assuming that client that see this for a denied lock will just assume
that it is denied by lockowner unknown, which is the same as it would
have to do for any other clientid.  As long as it not his clientid,
there isn't really isn't anything he can do with the lockowner 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.

The problem I see is that stateid's change because of other locks being
gotten and released by the same lockowner, even if the conflicting 
lock just stays there forever.   

> 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?

I don't think you can.