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

[Jeff Layton]

On Fri, 20 Jul 2007 10:15:43 -0500
"Steve French (smfltc)" <smfltc at us.ibm.com> wrote:

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

Not a bad idea. I'll reopen the BZ where I'm tracking this and see if
this might be doable.

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

I'm pretty sure this won't work. Since the unlock is done with 2 calls
and none of them cover the entire range of the lock, both unlock
calls would be ignored, correct?

It sounds like the above would be a good test though if we can get the
previous emulation you mentioned to work.

-- 
Jeff Layton <jlayton at redhat.com>