[linux-cifs-client] Re: unlocking part of a byte-range lock with, CIFS

[Steve French (smfltc)]

> One test that fails is lock test #10.
...
> fcntl(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=3}) = 0
> fcntl(3, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=1, len=1}) = 0
>
> ...but when I look at packet traces, I only see the first request go
> out on the wire. 

Jeremy has done some good talks on posix byte range locking vs. Windows
locking but what you are seeing is that overlapping posix locks are merged 
and a lock can be split by an unlock of part of the locked range, while 
Windows locks stack on top of each other, and the unlock is expected to
match the lock.  Perhaps a way to handle

lock bytes 1 through 3
unlock byte 2
would be to do

cifs lock bytes 1 through 3
cifs lock 1, cifs lock 3
unlock bytes 1 through 3

It would be fairly easy to emulate in lines 768 through 781 (current
mainline cifs) of fs/cifs/file.c   The current algorith unlocks the
stored (windows/cifs locks) that are within the lock request.

Have you tried a test such as the following to windows?

posix lock bytes 1 through 4 (which causes windows/cifs lock of bytes 1 through 4)
posix unlock bytes 1 and 2
posix unlock bytes 3 and 4  (which logically should cause the cifs lock to be removed)
then Try to write from another client to any of the presumably now unlocked bytes.