Re: posix_lock_file and blocking locks

[Steve French <smfrench@austin.rr.com>]

Trond Myklebust wrote:

>on den 15.12.2004 Klokka 09:39 (-0600) skreiv Steve French:
>
>  
>
>>For network filesystems (e.g. cifs, nfs), should we be calling calling
>>something other than posix_lock_file perhaps calling
>>posix_lock_file_wait (what is this call for?).
>>
>>    
>>
>
>They may wall posix_lock_file() for F_UNLCK type calls (since those
>never block), but for blocking locks, you probably should call
>posix_lock_file_wait().
>
>My guess is that what is happening here is something I've observed
>already on NFS systems: 
>	process 1 locks the file
>		process 2 tries to lock, but blocks on process 1.
>	process 1 calls the server that it should unlocks the file
>		the server notifies process 2 that it now has the lock before process
>1 receives its reply
>		process 2 calls posix_lock_file(), which puts the lock on the blocking
>list, then returns. Panic, when VFS tries to free that lock.
>
>So does the following patch help?
>
>Cheers,
>  Trond
>
>  
>
>------------------------------------------------------------------------
>
> file.c |    4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>Index: linux-2.6.10-rc3/fs/cifs/file.c
>===================================================================
>--- linux-2.6.10-rc3.orig/fs/cifs/file.c	2004-12-13 17:45:34.000000000 -0500
>+++ linux-2.6.10-rc3/fs/cifs/file.c	2004-12-15 16:18:21.514077956 -0500
>@@ -597,9 +597,9 @@ cifs_lock(struct file *file, int cmd, st
> 			 netfid, length,
> 			 pfLock->fl_start, numUnlock, numLock, lockType,
> 			 wait_flag);
>-	if (rc == 0 && (pfLock->fl_flags & FL_POSIX))
>-		posix_lock_file(file, pfLock);
> 	FreeXid(xid);
>+	if (rc == 0 && (pfLock->fl_flags & FL_POSIX))
>+		posix_lock_file_wait(file, pfLock);
> 	return rc;
> }
> 
>  
>
Yes - your suggested patch bypassed the kernel panic in fs/locks.c and 
the scenario you described as originally causing the nfs recreate is 
similar to what I see happening in cifs with "connectathon nfs" locktest 7.

I will merge this into the cifs bk tree.  This is probably worth pushing 
into mainline before 2.6.10 (if it is not already too late) as the 
kernel panic in fs/locks.c will affect some users.   I will do a bit 
more testing and send it.