[CRIU] [PATCH 1/2] Quick patch for error when writing mem.lim default
Pavel Emelyanov
xemul at parallels.com
Fri Aug 15 11:21:12 PDT 2014
On 08/15/2014 10:14 PM, Ying Han wrote:
>
>
>
> On Fri, Aug 15, 2014 at 11:03 AM, Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>> wrote:
>
> 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.
>
>
> Hmm. The one you mentioned above seems to be another patchset which is different from this one.
Ouch, sorry for confusing. After we agreed on the above Garrison split the patch
into two parts and resent a new series.
> This is purely to fix a bug where trying to write default value of memory.limit_in_bytes causes
> unclean restoration.
>
> Sorry If i am confused here.
>
> --Ying
>
>
> Thanks,
> Pavel
>
>
> >
> >
> > On Wed, Aug 13, 2014 at 11:59 AM, <gbellack at google.com <mailto:gbellack at google.com> <mailto:gbellack at google.com <mailto:gbellack at google.com>>> wrote:
> >
> > From: Garrison Bellack <gbellack at google.com <mailto:gbellack at google.com> <mailto: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> <mailto: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> <mailto:CRIU at openvz.org <mailto:CRIU at openvz.org>>
> > https://lists.openvz.org/mailman/listinfo/criu
> >
> >
>
>
More information about the CRIU
mailing list