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

[Garrison Bellack]

Pavel,

The patch above is completely independent from the missing properties
patches that I split into 2. Please merge this as it fixes a completely
unrelated bug.


On Fri, Aug 15, 2014 at 12:25 PM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> 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
> > .
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140815/12f1367f/attachment.html>