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

[Cyrill Gorcunov]

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