[OpenAFS-win32-devel] New client-side locking implementation

[asanka@secure-endpoints.com]

> > The problem here is with handling IRP_MN_UNLOCK_ALL, which involves 
> > knowing all the locks that were obtained using a specific 
> FileObject, 
> > and handling IRP_MN_UNLOCK_ALL_BY_KEY, which involves 
> knowing all the 
> > locks that were obtained using a specific FileObject and 
> > Parameters.*.Key.  Handling this
> 
> it is my understanding that IRP_MN_UNLOCK_ALL is a request to 
> remove all locks on the specified FileObject that are also 
> owned by the requesting process.  page 713 of Nagar's book 
> indicates this, and pg 714 further indicates that only the 
> owning process may remove locks.  there are similar semantics 
> for IRP_MN_UNLOCK_BY_KEY.

I stand corrected.  My initial interpretation of the docs was wrong about
the role of the process ID and Keys.

Our current understanding is that the Key, here, is used by processes that
perform proxy lock operations,  IRP_MN_UNLOCK_ALL should behave as you
mentioned, and IRP_MN_UNLOCK_ALL_BY_KEY should remove all locks that match
the FileObject, Process ID and Key.

> > situation wasn't a part of the design because the 
> > cm_Lock()/cm_Unlock() mechanism is not meant to deal with sets of 
> > locks; just one at a time.  This was supposed to be handled 
> at the SMB or IFS layer.
> 
> it seems redundant to manually keep track of locks in the 
> kernel for the sole purpose of dispatching an appropriate 
> number of unlock requests to the daemon.  (however, see end.)

Since you mentioned that you are using FsRtl* functions to process the locks
anyway, you are already keeping track of the locks that came through the IFS
side.

> > For IFS,
> >   InstanceKey = I_Key(IFS_MAGIC_SESSION_ID, I_ID(FileObject))
> >   ClientKey   = C_Key(IrpSp->Parameters.*.Key)
> 
> again, i believe InstanceKey must be based on both the 
> FileObject and the processID.

Agreed about the InstanceKey.  However...

> > ... If we are extending the CM to deal with batch unlocks.
>
> all of this secondary-keying could be mitigated if the IFS 
> version were to manually inspect each locking request, 
> compare it to known locks (FsRtlGetNextFileLock), and then 
> send the appropriate requests.  the trick in this case would 
> be to understand the request semantics properly so that the 
> lock lists would stay in sync.

Enumerating known locks through FsRtlGetNextFileLock should yield all the
relevant locks for an IRP_MN_UNLOCK_ALL_BY_KEY.  The list of locks that you
see when enumerating will probably not, and is not required to be in sync
with the list of locks kept in the CM.  However, there should be no locks in
the CM that are not in the file's FILE_LOCK which match the FileObject,
Process ID and Key for the request.  All such locks would have originated
from the IFS side and should already be in the FILE_LOCK.

If you are using a PUNLOCK_ROUTINE callback with FsRtlProcessFileLock, the
callback receives a PFILE_LOCK_INFO parameter that describes a single lock
at a time.  The PFILE_LOCK_INFO has enough information to make a call to
cm_Unlock() as originally suggested (with only one key derived from the
magic session, Process ID and FileObject).  You shouldn't need to enumerate
locks manually or depend on the CM knowing about the Key at all.  Confirm?

--asanka