[CRIU] [PATCH 2/2] lock: parse the lock field in fdinfo if it's avaliable

[Pavel Emelyanov]

On 04/20/2015 05:41 PM, Andrey Vagin wrote:

> @@ -1282,6 +1284,44 @@ static int parse_fdinfo_pid_s(int pid, int fd, int type,
>  			continue;
>  		}
>  
> +		if (fdinfo_field(str, "lock")) {
> +			struct file_lock *fl;
> +			struct fdinfo_common *fdinfo = arg;
> +
> +			if (type != FD_TYPES__UND)
> +				continue;
> +
> +			fl = alloc_file_lock();
> +			if (!fl) {
> +				pr_perror("Alloc file lock failed!");
> +				ret = -1;
> +				goto parse_err;
> +			}
> +
> +			if (parse_file_lock_buf(str + 6, fl, 0)) {
> +				xfree(fl);
> +				ret = -1;
> +				goto parse_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;
> +				xfree(fl);
> +				goto parse_err;
> +			}
> +
> +			fl->real_owner = fdinfo->owner;
> +			fl->owners_fd = fd;
> +			list_add_tail(&fl->list, &file_lock_list);

Is it enough for dump? Don't we need to make note_file_lock() skip its
magic in case of kerndat.has_lock?

> +		}
> +
>  		if (type == FD_TYPES__UND)
>  			continue;
>