Re: posix_lock_file and blocking locks

[Trond Myklebust <trond.myklebust@fys.uio.no>]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

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

-- 
Trond Myklebust <trond.myklebust@fys.uio.no>

[-- Attachment #2: linux-2.6.10-fix_cifslock.dif --]
[-- Type: text/plain, Size: 682 bytes --]

 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;
 }