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

[Pavel Emelyanov]

On 07/02/2013 03:26 PM, Cyrill Gorcunov wrote:
> On Tue, Jul 02, 2013 at 03:16:41PM +0400, Pavel Emelyanov wrote:
>>> +		if (nr_rlim < RLIM_NLIMITS) {
>>
>> This is always true for images got from rhel6 kernel. Why do we bother at all?
> 
> There is NO guarantee that image was not corrupted and there are a way
> more entries present on binary level. Thus when we read it in cycle
> 
> 	while (1) {
> 		RlimitEntry *re;
> 
> 		ret = pb_read_one_eof(fd, &re, PB_RLIMIT);
> 		if (ret <= 0)
> 			break;
> 
> 		if (nr_rlim < RLIM_NLIMITS) {
> 			struct rlimit *r = &ta->rlims[nr_rlim];
> 
> 			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);
> 		nr_rlim++;
> 	}
> 
> 	ta->nr_rlim = min(nr_rlim, RLIM_NLIMITS);
> 
> we don't wont to access out of array bound. Thus it's always true
> when criu has been compiled on new system, but on rhel6 it it's
> not true at all. OpenVZ image has own definition for RLIM_NLIMITS
> hardcoded to 16, and if criu compiled on rhel6 the system RLIM_NLIMITS
> is 15 -- thus we allocate only 15 entries in array.

1. We don't compile CRIU on rhel6.
2. Protection against "more rlimits in image, than in real-life" is there.

> .
>