[linux-cifs-client] posix_remove_lock oops in 2.6.13-rc

[Steven French]

Seems to me that the problem is that since the VFS is not requesting an
unlock of the locked range (rather a total file unlock from 0 to
MAX_OFFSET), the call on the server to unlock (via cifs) will fail so that
will cause the posix_lock_file_wait call to be skipped on the last unlock -
so that means that the remove_flock code will still see flocks hanging off
the inode (since the unlock in effect failed).

This is tricky to handle in CIFS since these really aren't posix locks but
they are somewhat close ... and like NFS, some apps will require a "nolock"
(or as cifs calls it "nobrl") mount option to skip all the remote locking
entirely in order to work.  We should not oops of course

At a minimum removing the "if rc==0" check on about line 646 of
fs/cifs/file.c is needed so the posix unlock call will actually occur on
the next line even if the server has no idea what lock we are trying to
unlock (the server/network protocol does not recognize 0 to MAX_OFFSET
which is presumably being done here as "unlock all locks" - there may be a
remote network ioctl or fcntl I can use that does this at least for the
case of NTFS - I will have to poke on that more - but the close on the
server will release the locks in any case so it is not as critical as it
sounds for the server to understand the "unlock all" concept).   For the
special case of 0 to MAX_OFFSET - I probably need to find code to walk all
byte range locks and unlock them all (remember cifs servers do not coalesce
locks so I will need to keep each of the underlying locks - which the local
kernel may have merged)


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-------------- next part --------------
HTML attachment scrubbed and removed