[CRIU] [PATCH] Fix restoring cgroup across hosts

[Hui Kang]

On Mon, Aug 10, 2015 at 11:16 AM, Tycho Andersen <
tycho.andersen at canonical.com> wrote:

> On Mon, Aug 10, 2015 at 03:00:42PM +0000, Hui Kang wrote:
> > The process to be restored may not have certain cgroup dir, e.g
> > cpu/[PID]/cpu.shares. Currently restoring  will fail in closing
> > the file. If this is the case, the fileno is -1 and we can ignore
> > this and let the restore proceed.
> >
> > Signed-off-by: Hui Kang <hkang.sunysb at gmail.com>
> > ---
> >  cgroup.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cgroup.c b/cgroup.c
> > index a4e0146..f4e49b3 100644
> > --- a/cgroup.c
> > +++ b/cgroup.c
> > @@ -974,7 +974,7 @@ static int restore_cgroup_prop(const CgroupPropEntry
> * cg_prop_entry_p,
> >               return -1;
> >       }
> >
> > -     if (fclose(f) != 0) {
> > +     if ((fclose(f) != 0) && (fileno(f) >= 0)) {
>
> If we put these in the other order we can avoid the fclose all
> together, I think.
>
>
Thanks for your suggestions. However, the fileno only turns to -1 after
fclose(f). This is because file is closed.
Prior to that, fileno(f) returns 5, which looks normal for
cgroup/cpu/cpus.share.



> Tycho
>
> >               pr_perror("Failed closing %s", path);
> >               return -1;
> >       }
> > --
> > 1.9.1
> >
> > _______________________________________________
> > 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/20150810/7ded1eb3/attachment.html>