From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: posix_lock_file and blocking locks Date: Wed, 15 Dec 2004 09:39:59 -0600 Message-ID: <1103125198.6135.45.camel@smfhome.smfdom> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from ms-smtp-04.texas.rr.com ([24.93.47.43]:38297 "EHLO ms-smtp-04.texas.rr.com") by vger.kernel.org with ESMTP id S262362AbULOPhB (ORCPT ); Wed, 15 Dec 2004 10:37:01 -0500 To: linux-fsdevel@vger.kernel.org, linux-cifs-client@lists.samba.org Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Can the posix_lock* calls work with the following case: 1) lock range1 2) lock succeeds 3) blocking lock on range1 - blocks waiting to get lock 4) unlock range1 5) unlock succeeds *** kernel generates panic Attempting to free lock with active block list 6) blocking lock succeeds 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?). Although before sending a byte range lock request to the server it would be helpful to have local vfs helper calls to see if the lock would: 1) suceed (if we know enough from the local system's perspective to know that the lock would fail - we might as well fail the request immediately) 2) change the state - A second lock sometimes has no effect since it is common practice in Unix (although apparently not required by POSIX) to "merge" overlapping locks - if a second lock would have no effect on the server (because it would be merged into an existing lock(s) which completely overlaps it) - it would be nice to be able to thow those lock requests away before sending them to the server Any idea if this is possible with the current fs/locks.c exports? Since the server already is keeping track of the locks for this inode the only reason I can see for calling posix_lock_file on the client (as was added in 2.6.9) would be to have the local client keep a list of the current lock state so it can replay them if the session server crashes (so the locks can be replayed when the server comes back up). Until I figure out a better way to store the local state of the locks - I don't see a way out of removing the call to posix_lock_file that was added to fs/cifs/file.c back in 2.6.9 (it causes the kernel panic in the case described above).