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

I started having a look at this scheme today, and hacked up a rough
implementation of the above logic. The problem I'm seeing is that the
overlapping lock requests are refused with STATUS_LOCK_NOT_GRANTED. I'm
presuming that the server (samba 3.0.25b) is refusing them since the
range is already considered to be locked.

To make this work, I do I need to make the original lock be shared
so that overlapping locks will work? If so, that might be a bit racy...

-- 
Jeff Layton <jlayton at redhat.com>