[CRIU] [PATCH] restore: Allow to ignore resource limits from image

Pavel Emelyanov xemul at parallels.com
Tue Jul 2 07:16:41 EDT 2013


On 07/02/2013 12:02 PM, Cyrill Gorcunov wrote:
> rhel6 has RLIM_NLIMITS defined to 15, while modern
> kernels increased this value to 16. So warn a user
> that some particular resource is ingnored on restore
> if criu built on rhel6 node.
> 
> More precisely -- this limit comes from not linux
> headers but from glibc-headers-2.12-1.80.el6.x86_64,
> thus even have kernel headers updated I still see
> this problem.
> 
> (the 16th resource is RLIMIT_RTTIME which is not present
>  on old system. If the container has been c/r with
>  criu from the scratch there won't be a problem, but
>  I'm testing containers which are snapshoted by openvz
>  kernel who has own CPT_RLIM_NLIMITS = 16 independently
>  of system headers).
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> ---
>  cr-restore.c | 33 +++++++++++++++++----------------
>  1 file changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/cr-restore.c b/cr-restore.c
> index 2146da2..774f379 100644
> --- a/cr-restore.c
> +++ b/cr-restore.c
> @@ -1808,9 +1808,9 @@ static unsigned long decode_rlim(u_int64_t ival)
>  
>  static int prepare_rlimits(int pid, struct task_restore_core_args *ta)
>  {
> -	int fd, ret;
> +	int fd, ret, nr_rlim;
>  
> -	ta->nr_rlim = 0;
> +	ta->nr_rlim = nr_rlim = 0;
>  
>  	fd = open_image(CR_FD_RLIMIT, O_RSTR, pid);
>  	if (fd < 0) {
> @@ -1823,32 +1823,33 @@ static int prepare_rlimits(int pid, struct task_restore_core_args *ta)
>  	}
>  
>  	while (1) {
> -		int l;
>  		RlimitEntry *re;
>  
>  		ret = pb_read_one_eof(fd, &re, PB_RLIMIT);
>  		if (ret <= 0)
>  			break;
>  
> -		l = ta->nr_rlim;
> -		if (l == RLIM_NLIMITS) {
> -			pr_err("Too many rlimits in image for %d\n", pid);
> -			ret = -1;
> -			break;
> -		}
> +		if (nr_rlim < RLIM_NLIMITS) {

This is always true for images got from rhel6 kernel. Why do we bother at all?

> +			struct rlimit *r = &ta->rlims[nr_rlim];
>  
> -		ta->rlims[l].rlim_cur = decode_rlim(re->cur);
> -		ta->rlims[l].rlim_max = decode_rlim(re->max);
> -		if (ta->rlims[l].rlim_cur > ta->rlims[l].rlim_max) {
> -			pr_err("Can't restore cur > max for %d.%d\n", pid, l);
> -			ta->rlims[l].rlim_cur = ta->rlims[l].rlim_max;
> +			r->rlim_cur = decode_rlim(re->cur);
> +			r->rlim_max = decode_rlim(re->max);
> +			if (r->rlim_cur > r->rlim_max) {
> +				pr_err("Can't restore cur > max for %d.%d\n",
> +				       pid, nr_rlim);
> +				r->rlim_cur = r->rlim_max;
> +			}
> +		} else {
> +			pr_warn("Resource limit %d ignored for %d\n",
> +				nr_rlim, pid);
>  		}
>  
>  		rlimit_entry__free_unpacked(re, NULL);
> -
> -		ta->nr_rlim++;
> +		nr_rlim++;
>  	}
>  
> +	ta->nr_rlim = min(nr_rlim, RLIM_NLIMITS);
> +
>  	close(fd);
>  	return ret;
>  }
> 




More information about the CRIU mailing list