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

[Pavel Emelyanov]

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?

>>> +static int do_open_pty_reg(int ns_root_fd, struct reg_file_info *rfi, void *v)
>>
>> This duplicates the do_open_reg_noseek_flags().
> 
> I know. I simply don't want to touch reg-files code as much as possible at least
> for the first tty series. Once it's known to work well I'll simplify it.

Please, don't generate duplicate code.

>>> +	/*
>>> +	 * Slave PTYs without master might have
>>> +	 * been postfixed as deleted, strip this
>>> +	 * part, we will need a valid path on their
>>> +	 * opening.
>>> +	 */
>>
>> 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.