aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/tty
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2011-06-08 10:46:30 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2011-06-08 10:46:30 -0400
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 f1a7918d71aa..6c9b7cd6778a 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)
413 spin_lock_irqsave(&tty->buf.lock, flags); 413 spin_lock_irqsave(&tty->buf.lock, flags);
414 414
415 if (!test_and_set_bit(TTY_FLUSHING, &tty->flags)) { 415 if (!test_and_set_bit(TTY_FLUSHING, &tty->flags)) {
416 struct tty_buffer *head, *tail = tty->buf.tail; 416 struct tty_buffer *head;
417 int seen_tail = 0;
418 while ((head = tty->buf.head) != NULL) { 417 while ((head = tty->buf.head) != NULL) {
419 int count; 418 int count;
420 char *char_buf; 419 char *char_buf;
@@ -424,15 +423,6 @@ static void flush_to_ldisc(struct work_struct *work)
424 if (!count) { 423 if (!count) {
425 if (head->next == NULL) 424 if (head->next == NULL)
426 break; 425 break;
427 /*
428 There's a possibility tty might get new buffer
429 added during the unlock window below. We could
430 end up spinning in here forever hogging the CPU
431 completely. To avoid this let's have a rest each
432 time we processed the tail buffer.
433 */
434 if (tail == head)
435 seen_tail = 1;
436 tty->buf.head = head->next; 426 tty->buf.head = head->next;
437 tty_buffer_free(tty, head); 427 tty_buffer_free(tty, head);
438 continue; 428 continue;
@@ -442,7 +432,7 @@ static void flush_to_ldisc(struct work_struct *work)
442 line discipline as we want to empty the queue */ 432 line discipline as we want to empty the queue */
443 if (test_bit(TTY_FLUSHPENDING, &tty->flags)) 433 if (test_bit(TTY_FLUSHPENDING, &tty->flags))
444 break; 434 break;
445 if (!tty->receive_room || seen_tail) 435 if (!tty->receive_room)
446 break; 436 break;
447 if (count > tty->receive_room) 437 if (count > tty->receive_room)
448 count = tty->receive_room; 438 count = tty->receive_room;