[CRIU] Re: [PATCH 10/10] files: Use sys_kcmp to find file descriptor duplicates

Cyrill Gorcunov gorcunov at openvz.org
Mon Feb 27 08:48:39 EST 2012


On Mon, Feb 27, 2012 at 05:34:38PM +0400, Pavel Emelyanov wrote:
> > +static struct fd_id_entry *
> > +lookup_alloc_subtree(struct fd_id_entry *e, u64 genid, pid_t pid, int fd)
> 
> OK, I like the overall idea. It should be written on wiki as a separate page,
> and a summary comment should be put here.

Yeah, I'll wrte the big comment here and probably draw a tree example.

...
> > +
> > +       rb_link_node(&sub->subtree_node, parent, new);
> > +       rb_insert_color(&sub->subtree_node, &e->subtree_root);
> 
> Same code in the below function. Merge them.
> 

OK

> > +
> > +       e = alloc_fd_id_entry(genid, pid, fd);
> > +       if (!e)
> > +               goto err;
> 
> Here the subid will be INVALID. This is ... wrong.
> 
> > +       rb_link_node(&e->node, parent, new);
> > +       rb_insert_color(&e->node, &fd_id_root);
> > +err:
> > +       return e;
> > +}
> > +

No, it's OK, the only _subsequent_ subid become a numbers from global
counter. Maybe I should simply rename FD_SUBID_INVALID to say FD_SUBID_FIRST
to eliminate confusion?

> > +struct fd_id_entry *fd_id_entry_collect(u64 genid, pid_t pid, int fd)
> > +{
> > +       return lookup_alloc(genid, pid, fd);
> 
> :\

Heh ;) Sure I'll merge it.

> 
> > +struct fd_id_entry {
> > +       struct rb_node  node;
> > +
> > +       struct rb_root  subtree_root;
> > +       struct rb_node  subtree_node;
> > +
> > +       u64             genid;  /* generic id, may have duplicates */
> > +       u64             subid;  /* subid is always unique */
> > +
> > +       pid_t           pid;
> > +       int             fd;
> > +} __aligned(sizeof(long));
> > +
> > +/* Position in file is u64 so we can't shrink it */
> > +#define MAKE_FD_GENID(dev, ino, pos) \
> > +       ((u64)(dev) ^ (u64)(ino) ^ (u64)(pos))
> 
> Since genid is just a hint, we can make it 32bit and just trim the pos.
> So can we make subid be 32 bit and ...
> 
> >  struct fdinfo_entry {
> >         u8      type;
> >         u8      len;
> >         u16     flags;
> >         u32     pos;
> >         u64     addr;
> > -       u8      id[FD_ID_SIZE];
> > +       u64     genid;
> > +       u64     subid;
> 
> ... make this a single 64bit ID field.
> 
> >         u8      name[0];
> >  } __packed;
> 

Sure we can do so but it potentially may increase the number
of syscalls we need to yield if position is somewhere on top
32 bits.

Pavel, while you at it -- the main problem is the fact itself
that we have two fields in image? I could make it simply
u64 id[2] then (it's still far better than u8 id[50] we've
had before then (it's still far better than u8 id[50] we've
had before :).

	Cyrill


More information about the CRIU mailing list