[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130817152853.GA24838@amd.pavel.ucw.cz>
Date: Sat, 17 Aug 2013 17:28:53 +0200
From: Pavel Machek <pavel@....cz>
To: Maximiliano Curia <maxy@...ian.org>
Cc: Peter Hurley <peter@...leysoftware.com>,
Margarita Manterola <margamanterola@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.cz>,
Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: Large pastes into readline enabled programs causes breakage
from v2.6.31 onwards
Hi!
> > n_tty_set_room() in drivers/tty/n_tty.c (3.10 mainline)
>
> > From n_tty_set_room():
>
> > /*
> > * If we are doing input canonicalization, and there are no
> > * pending newlines, let characters through without limit, so
> > * that erase characters will be handled. Other excess
> > * characters will be beeped.
> > */
> > if (left <= 0)
> > left = ldata->icanon && !ldata->canon_data;
> > old_left = tty->receive_room;
> > tty->receive_room = left;
>
> I took a long look at this code and thought about how it could be made to work
> for readline's case and also for the canonical readers. I came up with this
> simple patch:
>
> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> index 4bf0fc0..2ba7f4e 100644
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c
> @@ -149,7 +149,8 @@ static int set_room(struct tty_struct *tty)
> * characters will be beeped.
> */
> if (left <= 0)
> - left = ldata->icanon && !ldata->canon_data;
> + if (waitqueue_active(&tty->read_wait))
> + left = ldata->icanon && !ldata->canon_data;
> old_left = tty->receive_room;
> tty->receive_room = left;
>
> This is of course just an idea, but I tested this and it worked correctly for
> the cases I was testing.
>
> The effect of this patch is that when there is a canonical reader waiting for
> input, it maintains the previous behavior, but when there's no reader (like
> when readline is changing modes), it blocks and doesn't lose any characters.
>
> Another approach would be to recalculate the size of canon_data when the mode
> is changed, but this would probably be much more invasive, and awfully less
> efficient since it would imply going through the buffer.
>
> What do you think? Is the proposed solution, or something along those lines,
> acceptable?
>
> If there are other cases that need to be taken into account and that I
> currently don't know about, please let me know.
Was this applied? You may want to cc rjw... it is a regression, it is
not pretty, and it is something I blieve I hit but thought it was some
kind of "X weirdness".
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists