[CRIU] [PATCH] Fix restoring cgroup across hosts

[Tycho Andersen]

On Mon, Aug 10, 2015 at 12:30:47PM -0400, Hui Kang wrote:
> 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.

Ah, so doesn't this patch mask any error entirely then? As Pavel
points out, if the file doesn't exist, shouldn't the fopenat() give
you a bad fd?

Tycho

> 
> 
> > 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
> >