On Tue, 19 Aug 2008 19:56:39 +0200
That's linux-next, yes?
linux-next has additional locking in there:
commit 2283faa9cec083b6ddc1fa02a974ce1c797e847f
Author: Alan Cox <alan@redhat.com>
Date: Thu Aug 14 09:53:22 2008 +1000
tty-fix-pty-termios-race
Kanru Chen posted a patch versus the old code which deals with the case
where you resize the pty side of a pty/tty pair. In that situation the
termios data is updated for both pty and tty but the locks are not held
on both sides.
This reimplements the fix against the updated tty code. Patch by self but
the hard bit (noticing and fixing the bug) is thanks to Kanru Chen.
Signed-off-by: Alan Cox <alan@redhat.com>
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index a8ddcba..779c6b5 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -2068,7 +2068,7 @@ static int tiocgwinsz(struct tty_struct *tty, struct winsize __user *arg)
/**
* tty_do_resize - resize event
* @tty: tty being resized
- * @real_tty: real tty (if using a pty/tty pair)
+ * @real_tty: real tty (not the same as tty if using a pty/tty pair)
* @rows: rows (character)
* @cols: cols (character)
*
@@ -2085,6 +2085,14 @@ int tty_do_resize(struct tty_struct *tty, struct tty_struct *real_tty,
mutex_lock(&tty->termios_mutex);
if (!memcmp(ws, &tty->winsize, sizeof(*ws)))
goto done;
+
+ /* If a pty/tty pair is updated we will have a real_tty defined
+ which doesn't match the tty. In this case as we will update
+ both of the tty termios sets. We can lock both mutex safely here
+ as in this case real_tty is the tty, tty is the pty side and we
+ have lock ordering */
+ if (real_tty != tty)
+ mutex_lock(&real_tty->termios_mutex);
/* Get the PID values and reference them so we can
avoid holding the tty ctrl lock while sending signals */
spin_lock_irqsave(&tty->ctrl_lock, flags);
@@ -2102,6 +2110,8 @@ int tty_do_resize(struct tty_struct *tty, struct ...
