LU-451 Workaround for lockd (nfsv3) locking

It seems that lockd works in a different way lock-wise compared
to everybody else. They actually don't use lock owner to determine
conflicts and install their own owner compare that compares specially
crafted pids (duh!).
As a workaround if a custom owner compare is detected, assign pid to
owner field (not intersecting with kernel pointer space anyway).
svclock is the only place using custom owner compare function ATM.

Change-Id: Ia89e2327705f2afbe200fdbadd0f86038fda936d
Signed-off-by: Oleg Drokin <green@whamcloud.com>
Reviewed-on: http://review.whamcloud.com/1174
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Johann Lombardi <johann@whamcloud.com>
Reviewed-by: Alex Zhuravlev <bzzz@whamcloud.com>

diff --git a/lustre/llite/file.c b/lustre/llite/file.c
index c186b5a..4ca1911 100644 (file)
--- a/lustre/llite/file.c
+++ b/lustre/llite/file.c
@@ -2022,6 +2022,16 @@ int ll_file_flock(struct file *file, int cmd, struct file_lock *file_lock)
         }
         flock.l_flock.pid = file_lock->fl_pid;
 
+        /* Somewhat ugly workaround for svc lockd.
+         * lockd installs custom fl_lmops->fl_compare_owner that checks
+         * for the fl_owner to be the same (which it always is on local node
+         * I guess between lockd processes) and then compares pid.
+         * As such we assign pid to the owner field to make it all work,
+         * conflict with normal locks is unlikely since pid space and
+         * pointer space for current->files are not intersecting */
+        if (file_lock->fl_lmops && file_lock->fl_lmops->fl_compare_owner)
+                flock.l_flock.owner = (unsigned long)file_lock->fl_pid;
+
         switch (file_lock->fl_type) {
         case F_RDLCK:
                 einfo.ei_mode = LCK_PR;