[CRIU] [PATCH 5/5] tty: Use regular files engine to save paths to the peers, v3

[Cyrill Gorcunov]

On Wed, Oct 15, 2014 at 02:05:28PM +0400, Pavel Emelyanov wrote:
> On 10/15/2014 01:59 PM, Cyrill Gorcunov wrote:
> > On Wed, Oct 15, 2014 at 01:53:21PM +0400, Pavel Emelyanov wrote:
> >> On 10/13/2014 07:51 PM, Cyrill Gorcunov wrote:
> >>
> >>> @@ -242,18 +247,182 @@ static int tty_test_and_set(int bit, unsigned long *bitmap)
> >>>  	return ret;
> >>>  }
> >>>  
> >>> -static int pty_open_ptmx_index(int flags, int index)
> >>> +/*
> >>> + * Generate a regular file object in case if such is missed
> >>> + * in the image file, ie obsolete interface has been used on
> >>> + * checkpoint.
> >>> + */
> >>> +static struct file_desc *pty_alloc_fake_reg_d(struct tty_info *info, bool add)
> >>
> >> I'm not sure I understand the idea behind this alloc_fake. Can you elaborate?
> > 
> > If there are images created with older criu -- there won't be reg-files records
> > but I need to the rest of code to use reg-files engine (ie the code will be unified)
> > so for such case I create "fake" reg-files entries.
> 
> You also allocate these fakes for "unpaired slaves" and for "ctl terminal" unconditionally.
> What about these?

Yes, have to use fake peers here as well, previously we opened them explicitly by
paths but now we're switching to reg-files engine, so need fake reg-file enties too.

> >>
> >> This should be done on dump side. We have a problem right now with these
> >> "(deleted)" for link remaps and ghosts. Just introduce the function that
> >> strips this part for those and call the same for PTYs on dump.
> > 
> > Could you explain what problems we're facing with this postfix?
> 
> When we restore ghost/linkremap files kernel attached the 2nd one. When
> we C/R it again there appears the 3rd and so on.

This kind of crap should be handled on restore, not on dump. Maybe we better
strip this parts on read from image?