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

[Peter Staubach]

Steven French wrote:

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

Yes, the intention of the intention of the code in locks_remove_posix()
is to release and free all locks held by the specified owner.

So, does this imply that in the past, there were locks outstanding on the
server, unless the process itself, had released all of its locks manually?

    Thanx...

       ps