[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