[CRIU] [PATCH] tty: Don't flush tty data on checkpoint stage

[Andrey Wagin]

2012/11/22 Cyrill Gorcunov <gorcunov at openvz.org>:
> In case if we're dumping the peer which another
> end belongs not to us but some other application
> the attempts to flush data may lead to endless
> SIGTTOU storm:

We have endless SIGTTOU storm, if crtools dump is traced by strace.
If crtools dump is executed w/o strace, the dumping application is crashed.

I'm not sure, that we should not call ioctl(lfd, TCFLSH, TCIOFLUSH)
for all terminals. I think it should not be called for external
terminals.

>
>  | 1158  ioctl(53, TCFLSH, 0x2)            = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
>  | 1158  --- SIGTTOU {si_signo=SIGTTOU, si_code=SI_KERNEL, si_value={int=5, ptr=0x5}} ---
>  | 1158  --- stopped by SIGTTOU ---
>  | 1158  ioctl(53, TCFLSH, 0x2)            = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
>  | 1158  --- SIGTTOU {si_signo=SIGTTOU, si_code=SI_KERNEL, si_value={int=5, ptr=0x5}} ---
>  | 1158  --- stopped by SIGTTOU ---
>
> so simply don't flush data, the initial attempt to use
> TCIOFLUSH was rather "hey, we don't have a way to
> say the kernel to freeze tty link for a while, lets
> try to workaround this limitation" but without proper
> kernel help this won't work anyway as Andrey has discovered.
>
> Reported-by: Andrey Vagin <avagin at openvz.org>
> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> ---
>  tty.c |   11 ++++++++++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/tty.c b/tty.c
> index 1ecb0e5..6009850 100644
> --- a/tty.c
> +++ b/tty.c
> @@ -1158,8 +1158,17 @@ static int dump_one_pty(int lfd, u32 id, const struct fd_parms *p)
>          * we don't check for errors here since it makes
>          * no sense anyway, the buffered data is not handled
>          * properly yet.
> +        *
> +        * Note as well that if we have only one peer here
> +        * the external end might be sending the data to us
> +        * again and again while kernel buffer is not full,
> +        * this might lead to endless SIGTTOU signal delivery
> +        * to the dumpee, ruining checkpoint procedure.
> +        *
> +        * So simply do not flush the line while we dump
> +        * parameters tty never was being a guaranteed delivery
> +        * transport anyway.
>          */
> -       ioctl(lfd, TCFLSH, TCIOFLUSH);
>
>         if (!tty_test_and_set(e.tty_info_id, tty_bitmap))
>                 ret = dump_pty_info(lfd, e.tty_info_id, p, major, index);
> --
> 1.7.7.6
>