dump: check the --file-locks flags when dumping.

Submitted by lixiaoguang2@huawei.com on Nov. 26, 2020, 9:55 a.m.

Details

Message ID 20201126095529.1938-1-lixiaoguang2@huawei.com
State New
Series "dump: check the --file-locks flags when dumping."
Headers show

Commit Message

lixiaoguang2@huawei.com Nov. 26, 2020, 9:55 a.m.
From: Xiaoguang Li <lixiaoguang2@huawei.com>

When the --file-locks is not used, it still dump the file-locks
msg to image file. We need to check the --file-locks flags when dumping

Signed-off-by: Xiaoguang Li <lixiaoguang2@huawei.com>
---
 criu/file-lock.c | 3 +++
 1 file changed, 3 insertions(+)

Patch hide | download patch | download mbox

diff --git a/criu/file-lock.c b/criu/file-lock.c
index 8be7589df..f80c2c305 100644
--- a/criu/file-lock.c
+++ b/criu/file-lock.c
@@ -91,6 +91,9 @@  static void fill_flock_entry(FileLockEntry *fle, int fl_kind, int fl_ltype)
 
 int dump_file_locks(void)
 {
+	if (!opts.handle_file_locks)
+		return 0;
+
 	FileLockEntry	 fle;
 	struct file_lock *fl;
 	int	ret = 0;

Comments

Pavel Tikhomirov Dec. 8, 2020, 9:35 a.m.
If we exclude unix SCMs file locks are simple as:

(note call stacks are in reverse order the leftmost function is deepest in
stack)

# here we get info about locks on open files from fdinfo and setup
# file_lock_list

  +-< parse_fdinfo_pid_s
    +-< parse_fdinfo_pid
      +-< fill_fd_params
        +-< dump_one_file (2)
          +-< dump_task_files_seized
            +-< dump_one_task
              +-< cr_dump_tasks (1)

# or here if there are no fdinfo locks

  +-< parse_file_locks
    +-< collect_file_locks # before dump_one_task
      +-< cr_dump_tasks (1)

# here we detect that file lock is held and fail if no option
# opts.handle_file_locks provided

  +-< note_file_lock # after fill_fd_params
    +-< dump_one_file (2)

# so if we got to:

  +-< dump_file_locks # after dump_one_task
    +-< cr_dump_tasks (1)

# we either have empty file_lock_list or have opts.handle_file_locks set or we
# have some "fantom" locks which are held but not on files of processes we
# dump, so probably we should not care about them.

To conclude, in my understanding your patch is excess.

Note: desired way to "send" patches to CRIU is through pull requests,
please do it through pull requests next time if there is no difference
for you. see https://github.com/checkpoint-restore/criu/pull/1297

Best Regards, Tikhomirov Pavel.

чт, 26 нояб. 2020 г. в 13:02, <lixiaoguang2@huawei.com>:
>
> From: Xiaoguang Li <lixiaoguang2@huawei.com>
>
> When the --file-locks is not used, it still dump the file-locks
> msg to image file. We need to check the --file-locks flags when dumping
>
> Signed-off-by: Xiaoguang Li <lixiaoguang2@huawei.com>
> ---
>  criu/file-lock.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/criu/file-lock.c b/criu/file-lock.c
> index 8be7589df..f80c2c305 100644
> --- a/criu/file-lock.c
> +++ b/criu/file-lock.c
> @@ -91,6 +91,9 @@ static void fill_flock_entry(FileLockEntry *fle, int fl_kind, int fl_ltype)
>
>  int dump_file_locks(void)
>  {
> +       if (!opts.handle_file_locks)
> +               return 0;
> +
>         FileLockEntry    fle;
>         struct file_lock *fl;
>         int     ret = 0;
> --
> 2.28.0.windows.1
>
> _______________________________________________
> CRIU mailing list
> CRIU@openvz.org
> https://lists.openvz.org/mailman/listinfo/criu