aboutsummaryrefslogtreecommitdiff
path: root/drivers/tty
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2011-06-08 07:46:30 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-06-08 07:46:30 -0700
commit81de916f19cf5f1437c0b9ed817364f0f7c81961 (patch)
tree5c1cda4a096ae3b821a5917de5984b1a16079707 /drivers/tty
parentcb0a02ecf95e5f47d92e7d4c513cc1f7aeb40cda (diff)
tty_buffer: get rid of 'seen_tail' logic in flush_to_ldisc
The flush_to_ldisc() work entry has special logic to notice when it has seen the original tail of the data queue, and it avoids continuing the flush if it sees that _original_ tail rather than the current tail. This logic can trigger in case somebody is constantly adding new data to the tty while the flushing is active - and the intent is to avoid excessive CPU usage while flushing the tty, especially as we used to do this from a softirq context which made it non-preemptible. However, since we no longer re-arm the work-queue from within itself (because that causes other trouble: see commit a5660b41af6a "tty: fix endless work loop when the buffer fills up"), this just leads to possible hung tty's (most easily seen in SMP and with a test-program that floods a pty with data - nobody seems to have reported this for any real-life situation yet). And since the workqueue isn't done from timers and softirq's any more, it's doubtful whether the CPU useage issue is really relevant any more. So just remove the logic entirely, and see if anybody ever notices. Alternatively, we might want to re-introduce the "re-arm the work" for just this case, but then we'd have to re-introduce the delayed work model or some explicit timer, which really doesn't seem worth it for this. Reported-and-tested-by: Guillaume Chazarain <guichaz@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/tty')
-rw-r--r--drivers/tty/tty_buffer.c14
1 files changed, 2 insertions, 12 deletions
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index f1a7918d71a..6c9b7cd6778 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -413,8 +413,7 @@ static void flush_to_ldisc(struct work_struct *work)
spin_lock_irqsave(&tty->buf.lock, flags);
if (!test_and_set_bit(TTY_FLUSHING, &tty->flags)) {
- struct tty_buffer *head, *tail = tty->buf.tail;
- int seen_tail = 0;
+ struct tty_buffer *head;
while ((head = tty->buf.head) != NULL) {
int count;
char *char_buf;
@@ -424,15 +423,6 @@ static void flush_to_ldisc(struct work_struct *work)
if (!count) {
if (head->next == NULL)
break;
- /*
- There's a possibility tty might get new buffer
- added during the unlock window below. We could
- end up spinning in here forever hogging the CPU
- completely. To avoid this let's have a rest each
- time we processed the tail buffer.
- */
- if (tail == head)
- seen_tail = 1;
tty->buf.head = head->next;
tty_buffer_free(tty, head);
continue;
@@ -442,7 +432,7 @@ static void flush_to_ldisc(struct work_struct *work)
line discipline as we want to empty the queue */
if (test_bit(TTY_FLUSHPENDING, &tty->flags))
break;
- if (!tty->receive_room || seen_tail)
+ if (!tty->receive_room)
break;
if (count > tty->receive_room)
count = tty->receive_room;