From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: Re: posix_lock_file and blocking locks Date: Wed, 15 Dec 2004 18:51:09 -0600 Message-ID: <41C0DBFD.60605@austin.rr.com> References: <1103125198.6135.45.camel@smfhome.smfdom> <1103145976.26193.38.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Linux Filesystem Development , akpm@osdl.org, linux-cifs-client@lists.samba.org Return-path: To: Trond Myklebust In-Reply-To: <1103145976.26193.38.camel@lade.trondhjem.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-cifs-client-bounces+glfc-linux-cifs-client=gmane.org@lists.samba.org Errors-To: linux-cifs-client-bounces+glfc-linux-cifs-client=gmane.org@lists.samba.org List-Id: linux-fsdevel.vger.kernel.org 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.