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

[Pavel Emelyanov]

On 10/15/2014 02:21 PM, Cyrill Gorcunov wrote:
> 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.

But you allocate more than just a reg-file entry. You allocate
the whole tty-info. What for?

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

No. We should have in the image "real" file name, not the one kernel
generated for us. If you need it, add an optional bool was_deleted
flag in the reg-file image, but we already have the needed into in
the remap image.