posix_lock_file and blocking locks

[Steve French <smfrench@austin.rr.com>]

Can the posix_lock* calls work with the following case:

1) lock range1
2) lock succeeds
3) blocking lock on range1 - blocks waiting to get lock
4) unlock range1
5) unlock succeeds
   *** kernel generates panic
	Attempting to free lock with active block list
6) blocking lock succeeds

For network filesystems (e.g. cifs, nfs), should we be calling calling
something other than posix_lock_file perhaps calling
posix_lock_file_wait (what is this call for?).

Although before sending a byte range lock request to the server it would
be helpful to have local vfs helper calls to see if the lock would:
1) suceed (if we know enough from the local system's perspective to know
that the lock would fail - we might as well fail the request
immediately)
2) change the state - A second lock sometimes has no effect since it is
common practice in Unix (although apparently not required by POSIX) to
"merge" overlapping locks - if a second lock would have no effect on the
server (because it would be merged into an existing lock(s) which
completely overlaps it) - it would be nice to be able to thow those lock
requests away before sending them to the server

Any idea if this is possible with the current fs/locks.c exports?

Since the server already is keeping track of the locks for this inode
the only reason I can see for calling posix_lock_file on the client (as
was added in 2.6.9) would be to have the local client keep a list of the
current lock state so it can replay them if the session server crashes
(so the locks can be replayed when the server comes back up). 

Until I figure out a better way to store the local state of the locks -
I don't see a way out of removing the call to posix_lock_file that was
added to fs/cifs/file.c back in 2.6.9 (it causes the kernel panic in the
case described above).