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

[Jeff Layton]

I've been testing with the connectathon tests on CIFS. With posix
extensions everything works correctly, but without them some tests
fail. There are probably good reasons for it, but I'm trying to
determine what they are (mostly for my own education...)

One test that fails is lock test #10. I've tracked down the cause, but
it looks deliberate and I'm unsure of the reasoning. The test
essentially does this on a file:

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. The second one never does. Later, when a different
process tries to lock that byte, it fails when it should succeed.

The cifs_lock code has this:

  } else if (numUnlock) {
        /* For each stored lock that this unlock overlaps
           completely, unlock it. */

...and the code seems to make the above unlock a no-op. Why does the
unlock need to overlap completely here? Is this some limitation of the
CIFS protocol or is this a bug?

-- 
Jeff Layton <jlayton at redhat.com>