tty: Don't flush tty data on checkpoint stage

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:

 | 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@openvz.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

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);