[CRIU] [PATCH] flock: blocked processes are not interesting for us

[Andrey Vagin]

All out processes are stopped in a moment, when file locks are
collected, so they can't to wait any locks.

Here is a proof of this theory:
[root at avagin-fc19-cr ~]# flock xxx sleep 1000 &
[1] 23278
[root at avagin-fc19-cr ~]# flock xxx sleep 1000 &
[2] 23280
[root at avagin-fc19-cr ~]# cat /proc/locks
1: FLOCK  ADVISORY  WRITE 23278 08:03:280001 0 EOF
1: -> FLOCK  ADVISORY  WRITE 23280 08:03:280001 0 EOF
[root at avagin-fc19-cr ~]# gdb -p 23280
(gdb) ^Z
[3]+  Stopped                 gdb -p 23280
[root at avagin-fc19-cr ~]# cat /proc/locks
1: FLOCK  ADVISORY  WRITE 23278 08:03:280001 0 EOF

Currently criu can dump nothing, if we have one process which is
waiting a lock. I don't see any reason to do this.

Cc: Qiang Huang <h.huangqiang at huawei.com>
Reported-by: Mr Jenkins
Signed-off-by: Andrey Vagin <avagin at openvz.org>
---
 proc_parse.c | 36 ++++++++++++++++--------------------
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/proc_parse.c b/proc_parse.c
index 389cb72..b1afb61 100644
--- a/proc_parse.c
+++ b/proc_parse.c
@@ -1501,6 +1501,12 @@ int parse_file_locks(void)
 			goto err;
 		}
 
+		pr_info("lockinfo: %lld:%d %x %d %02x:%02x:%ld %lld %s\n",
+			fl->fl_id, fl->fl_kind, fl->fl_ltype,
+			fl->fl_owner, fl->maj, fl->min, fl->i_no,
+			fl->start, fl->end);
+
+
 		if (fl->fl_kind == FL_UNKNOWN) {
 			pr_err("Unknown file lock!\n");
 			ret = -1;
@@ -1508,6 +1514,16 @@ int parse_file_locks(void)
 			goto err;
 		}
 
+		if (is_blocked) {
+			/*
+			 * All target processes are stopped in this moment and
+			 * can't wait any locks.
+			 */
+			pr_debug("Skip blocked processes\n");
+			xfree(fl);
+			goto err;
+		}
+
 		if ((fl->fl_kind == FL_POSIX) &&
 				!pid_in_pstree(fl->fl_owner)) {
 			/*
@@ -1519,26 +1535,6 @@ int parse_file_locks(void)
 			continue;
 		}
 
-		pr_info("lockinfo: %lld:%d %x %d %02x:%02x:%ld %lld %s\n",
-			fl->fl_id, fl->fl_kind, fl->fl_ltype,
-			fl->fl_owner, fl->maj, fl->min, fl->i_no,
-			fl->start, fl->end);
-
-		if (is_blocked) {
-			/*
-			 * Here the task is in the pstree.
-			 * If it is blocked on a flock, when we try to
-			 * ptrace-seize it, the kernel will unblock task
-			 * from flock and will stop it in another place.
-			 * So in dumping, a blocked file lock should never
-			 * be here.
-			 */
-			pr_perror("We have a blocked file lock!");
-			ret = -1;
-			xfree(fl);
-			goto err;
-		}
-
 		list_add_tail(&fl->list, &file_lock_list);
 	}
 
-- 
1.9.3