From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wendy Cheng Date: Mon, 07 Jan 2008 00:53:54 -0500 Subject: [Cluster-devel] [PATCH 2/2] Fix lockd panic Message-ID: <4781BE72.7050404@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This small patch has not been changed since our last discussion: http://www.opensubscriber.com/message/nfs at lists.sourceforge.net/6348912.html To recap the issue, a client could ask for a posix lock that invokes: >>> server calls nlm4svc_proc_lock() -> >>> * server lookup file (f_count++) >>> * server lock the file >>> * server calls nlm_release_host >>> * server calls nlm_release_file (f_count--) >>> * server return to client with status 0 >>> As part of the lookup file, the lock stays on vfs inode->i_flock list with zero f_count. Any call into nlm_traverse_files() will BUG() in locks_remove_flock() (fs/locks.c:2034) during fclose(), if that file happens to be of no interest to that particular search. Since after nlm_inspect_file(), the logic unconditionally checks for possible removing of the file. As the file is not blocked, nothing to do with shares, and f_count is zero, it will get removed from hash and fclose() invoked with the posix lock hanging on i_flock list. -- Wendy -------------- next part -------------- A non-text attachment was scrubbed... Name: unlock_002.patch Type: text/x-patch Size: 939 bytes Desc: not available URL: