[CRIU] [PATCH] criu: tty -- Restore tty params synchronously

Pavel Emelyanov xemul at virtuozzo.com
Wed May 4 00:22:17 PDT 2016


On 04/28/2016 01:18 PM, Cyrill Gorcunov wrote:
> On Thu, Apr 21, 2016 at 9:02 PM, Cyrill Gorcunov <gorcunov at gmail.com> wrote:
>> On Thu, Apr 21, 2016 at 08:48:49PM +0300, Pavel Emelyanov wrote:
>>>>>
>>>>> But the restore fails anyway, so we do we care?
>>>>
>>>> Yes we care. The restoration of params must be done on alive terminals.
>>>
>>> OK, but if terminal is dead, then the restore is failing. So why not
>>> have one more failure in logs?
>>
>> Because in this case we don't control when real async ioctl is called,
>> as far as I understand we may hit it earlier and hide real case of
>> problem.
>>
>> After all your questions, I started doubting if the changelog is correct.
>> For sure the reason of failure is async ioctl call over terminal
>> which is not alive (since with the patch container passes this point
>> of restore) but maybe I've overlooked something. Gimme some time...
> 
> You know, we may fail inbetween, having restore-tty-params request in the fly.
> Imagine
> 
> pty_open_unpaired_slave
> pty_open_slaves
>   ...
>   fd = open_tty_reg()
>   restore_tty_params --> sends request
>   send_fd_to_peer(fd) -> it fails
>   close_safe(&fd);
>   return -1;
> now pty_open_unpaired_slave will close the master but then in-flight
> request may start and will exit with error.

Still, send_fd_to_peer() failed and we exit with error anyway.

> Moreover I think we should not call userns_call if there is no p.has
> set. I will optimize it on top.
> So please merge this patch.
> .
> 



More information about the CRIU mailing list