[packages/kernel/LINUX_3_10] - add patch to fix large pastes into readline enabled programs

[baggins]

commit a0fe81df5fd4c499e452740db43b6e93bc6f5571
Author: Jan Rękorajski <baggins at pld-linux.org>
Date:   Mon Nov 18 13:00:31 2013 +0100

    - add patch to fix large pastes into readline enabled programs

 kernel-large-readline-paste.patch | 96 +++++++++++++++++++++++++++++++++++++++
 kernel.spec                       |  6 +++
 2 files changed, 102 insertions(+)
---
diff --git a/kernel.spec b/kernel.spec
index 5855261..85706b1 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -224,6 +224,10 @@ Patch146:	kernel-aufs3+vserver.patch
 # Show normal colors in menuconfig with ncurses ABI 6
 Patch250:	kernel-fix_256colors_menuconfig.patch
 
+# https://lkml.org/lkml/2013/9/3/539
+# fill thread: https://lkml.org/lkml/2013/7/25/205
+Patch300:	kernel-large-readline-paste.patch
+
 # https://patchwork.kernel.org/patch/236261/
 Patch400:	kernel-virtio-gl-accel.patch
 
@@ -715,6 +719,8 @@ cd linux-%{basever}
 
 %patch250 -p1
 
+%patch300 -p1
+
 # virtio-gl
 %patch400 -p1
 
diff --git a/kernel-large-readline-paste.patch b/kernel-large-readline-paste.patch
new file mode 100644
index 0000000..8d76304
--- /dev/null
+++ b/kernel-large-readline-paste.patch
@@ -0,0 +1,96 @@
+�Hola Peter!
+
+El 2013-08-19 a las 08:25 -0400, Peter Hurley escribi�:
+> My primary concern is canonical readers not become stuck with a full
+> read buffer, even with bogus input data (IOW, that an error condition will
+> not prevent a reader from making forward progress). I believe that won't
+> happen with this change, but what I really need in this case is a detailed
+> analysis from you of why that won't happen. That analysis should be in
+> the patch changelog. (Feel free to send me private mail if you need help
+> preparing a patch.)
+
+I'm not sure what level of analysis you are looking for. The driver will block
+when there are no readers but as soon as there is a read call it unblocks.
+I've added this information to the patch description that I'm including below.
+
+> And the patch above has a bug that allows a negative 'left' to be
+> assigned to tty->receive_room which will be interpreted as a very large
+> positive value.
+
+Ok, fixed with an else clause. It could also use an extra &&, but it looks a
+bit confusing.
+
+> This approach still has several drawbacks.
+
+> 1) Since additional state is reset when the termios is changed by
+> readline(), the canonical line buffer state will be bogus.
+> This renders the termios change by readline() pointless; the
+> caller will not be able to retrieve expected input properly.
+
+> 2) Since the input data is interpreted with the current termios when
+> data is received, any embedded control characters will not be
+> interpreted properly; again, the caller will not be able to retrieve
+> expected input properly.
+
+Indeed this is correct, however this is not an issue of this patch but of the
+current interaction between the kernel and readline. In order to fix this, the
+reading buffer should always be in raw and only when responding to a read call
+for canonical mode should it be interpreted. This is a very big change, and
+I'm not sure if anybody will be interested in implementing it.
+
+> >What do you think? Is the proposed solution, or something along those lines,
+> >acceptable?
+
+> I'm wondering if this problem might be best addressed on the paste side
+> instead of the read side. Although this wouldn't be a magic bullet, it
+> would be easier to control when more paste data is added.
+
+I don't see how this could work, could you elaborate?
+
+This is the patch proposal, for comments:
+
+From 81afd3b666cbf94bb9923ebf87fb2017a7cd645e Mon Sep 17 00:00:00 2001
+From: Maximiliano Curia <maxy at gnuservers.com.ar>
+Date: Tue, 3 Sep 2013 22:48:34 +0200
+Subject: [PATCH] Only let characters through when there are active readers.
+
+If there is an active reader, previous behavior is in place. When there is no
+active reader, input is blocked until the next read call unblocks it.
+
+This fixes a long standing issue with readline when pasting more than 4096
+bytes.
+---
+ drivers/tty/n_tty.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
+index 4bf0fc0..cdc3b19 100644
+--- a/drivers/tty/n_tty.c
++++ b/drivers/tty/n_tty.c
+@@ -147,9 +147,16 @@ static int set_room(struct tty_struct *tty)
+ 	 * pending newlines, let characters through without limit, so
+ 	 * that erase characters will be handled.  Other excess
+ 	 * characters will be beeped.
++	 * If there is no reader waiting for the input, block instead of
++	 * letting the characters through.
+ 	 */
+ 	if (left <= 0)
+-		left = ldata->icanon && !ldata->canon_data;
++		if (waitqueue_active(&tty->read_wait)) {
++			left = ldata->icanon && !ldata->canon_data;
++		} else {
++			left = 0;
++		}
++
+ 	old_left = tty->receive_room;
+ 	tty->receive_room = left;
+ 
+-- 
+1.8.4.rc3
+
+
+-- 
+"Always code as if the person who ends up maintaining your code is a violent
+psychopath who knows where you live."
+-- John Woods
+Saludos /\/\ /\ >< `/
================================================================

---- gitweb:

http://git.pld-linux.org/gitweb.cgi/packages/kernel.git/commitdiff/00b79b8921afe5481f79737de26b127a545cb806