Re: [PATCH 7/9] tty : kill receive_room usage in tty_buffer
From: Alan Cox <hidden>
Date: 2012-03-05 10:30:13
On Sun, 4 Mar 2012 18:59:18 +0100 Matthieu CASTET [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr> --- drivers/tty/tty_buffer.c | 10 ++++------ 1 files changed, 4 insertions(+), 6 deletions(-)diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c index 0e0f0fa..8cc7ceb 100644 --- a/drivers/tty/tty_buffer.c +++ b/drivers/tty/tty_buffer.c@@ -437,17 +437,15 @@ static void flush_to_ldisc(struct work_struct *work) */ if (test_bit(TTY_LDISC_CHANGING, &tty->flags)) break; - if (!tty->receive_room) - break; - if (count > tty->receive_room) - count = tty->receive_room; char_buf = head->char_buf_ptr + head->read; flag_buf = head->flag_buf_ptr + head->read; - head->read += count; spin_unlock_irqrestore(&tty->buf.lock, flags); - disc->ops->receive_buf(tty, char_buf, + count = disc->ops->receive_buf(tty, char_buf, flag_buf, count); spin_lock_irqsave(&tty->buf.lock, flags); + if (count == 0) + break; + head->read += count;
If you've not fixed the parallel calls bugs head->read can now be invalid. Previously it was at least vaguely self consistent because the lock was held for the entire calculation and head->read set up before the buffer want to the ldisc, now its updated some arbitary time in the future by which point one of the buggy parallel callers may have messed it up.