[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