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

[Jeff Layton]

On Fri, 24 Aug 2007 09:32:38 -0700
Jeremy Allison <jra at samba.org> wrote:

> On Fri, Aug 24, 2007 at 09:29:03AM -0400, Jeff Layton wrote:
> > 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...
> 
> This won't work. You can't overlap existing locks in CIFS. Actually
> you can but it's a bit complicated and in no way POSIX-friendly :-).
> 
> Bug me if you need more details.
> 

Thanks. I don't want to take up your time, but it would be good to
settle whether this is completely unfixable...

I saw this in one of your slide decks, so I'm guessing this
is what you mean?

Locks can't overlap, or be split or merged
  (as they can in POSIX), but read locks can
  be "stacked" on top of a write lock.
  - So long as the same locking context is used.

Or is it more complicated than this? :-)

-- 
Jeff Layton <jlayton at redhat.com>