[CRIU] [PATCH 1/2] Quick patch for error when writing mem.lim default

Pavel Emelyanov xemul at parallels.com
Fri Aug 15 12:25:09 PDT 2014


On 08/15/2014 11:15 PM, Serge Hallyn wrote:
> That's going to be a painful thing to do item-by-item.  One way to address
> this - not urgent to do soon imo - would be to have the restart mark itself
> as failed, but not immediately halt;  have it write outa a file with all of
> the absent features;  Then the user edits that file marking all of the
> ok-to-ignore things, and passes it in with a '--ignore-absent <file>'
> argument, which criu then honors.

I like the idea to postpone the failure and ask the caller what to do.
How about pushing the list of not found properties into the "post-restore"
script letting it decide what to do next? Or even introduce yet another 
one, e.g. "cgroup-restore".

> Just a thought, but it seems like the only sane way to handle it.
> 
> Quoting Pavel Emelyanov (xemul at parallels.com):
>> On 08/15/2014 08:54 PM, Ying Han wrote:
>>> Ping?
>>
>> We all agreed to commit the change that makes _dumping_ of absent properties
>> non-fatal (I'll do that soon). As far as writing is concerned -- it looks like
>> just ignoring the absence of properties from image dumps is not good as generic
>> solution. Instead, for restore we need some fine-grained control over which
>> properties to restore and which to ignore.
>>
>> Thanks,
>> Pavel
>>
>>
>>>
>>>
>>> On Wed, Aug 13, 2014 at 11:59 AM, <gbellack at google.com <mailto:gbellack at google.com>> wrote:
>>>
>>>     From: Garrison Bellack <gbellack at google.com <mailto:gbellack at google.com>>
>>>
>>>     When writing the system default for memory.limit_in_bytes (which is a LLONG_MAX)
>>>     the write fails. The number is equivalent to -1 (unlimited). So during dump,
>>>     store the number -1 instead.
>>>
>>>     Change-Id: Iafccc96bf5dbade763d7addaeda24194616e4d5f
>>>     Signed-off-by: Garrison Bellack <gbellack at google.com <mailto:gbellack at google.com>>
>>>     ---
>>>      cgroup.c | 9 +++++++++
>>>      1 file changed, 9 insertions(+)
>>>
>>>     diff --git a/cgroup.c b/cgroup.c
>>>     index 7ac2dd8..f8dbbde 100644
>>>     --- a/cgroup.c
>>>     +++ b/cgroup.c
>>>     @@ -288,6 +288,7 @@ static int read_cgroup_prop(struct cgroup_prop *property, const char *fpath)
>>>      {
>>>             char pbuf[PATH_MAX], buf[100];
>>>             FILE *f;
>>>     +       char *endptr;
>>>
>>>             if (snprintf(pbuf, PATH_MAX, "%s/%s", fpath, property->name) >= PATH_MAX) {
>>>                     pr_err("snprintf output was truncated");
>>>     @@ -315,6 +316,14 @@ static int read_cgroup_prop(struct cgroup_prop *property, const char *fpath)
>>>                     return -1;
>>>             }
>>>
>>>     +       if (strtoll(buf, &endptr, 10) == LLONG_MAX)
>>>     +               strcpy(buf, "-1");
>>>     +
>>>     +       if (strcmp(endptr, "\n")) {
>>>     +               pr_perror("Failed parsing %s, with strtoll\n", buf);
>>>     +               return -1;
>>>     +       }
>>>     +
>>>             property->value = xstrdup(buf);
>>>             if (!property->value)
>>>                     return -1;
>>>     --
>>>     2.1.0.rc2.206.gedb03e5
>>>
>>>     _______________________________________________
>>>     CRIU mailing list
>>>     CRIU at openvz.org <mailto:CRIU at openvz.org>
>>>     https://lists.openvz.org/mailman/listinfo/criu
>>>
>>>
>>
>> _______________________________________________
>> CRIU mailing list
>> CRIU at openvz.org
>> https://lists.openvz.org/mailman/listinfo/criu
> .
> 



More information about the CRIU mailing list