Re: [2.6.33-rc5] tty: possible irq lock inversion dependency in tty_fasync

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 7 Feb 2010, Tetsuo Handa wrote:
> 
> Below problem (which was introduced between 2.6.33-rc4 and 2.6.33-rc5) is
> not yet fixed as of 2.6.33-rc7.
> "git bisect start v2.6.33-rc5 v2.6.33-rc4" reported that
> 703625118069f9f8960d356676662d3db5a9d116 tty: fix race in tty_fasync
> is first bad commit.

Yeah. I think we need to just revert that commit.

Or maybe we could just do the following, rather than revert it outright: 
just get a ref to the 'struct pid' while holding the spinlock, and then 
releasing it after doing the __f_setown() call.

That way we know 'pid' isn't going away.

What? Untested, of course.

			Linus

---
 drivers/char/tty_io.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index c6f3b48..dcb9083 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1951,8 +1951,10 @@ static int tty_fasync(int fd, struct file *filp, int on)
 			pid = task_pid(current);
 			type = PIDTYPE_PID;
 		}
-		retval = __f_setown(filp, pid, type, 0);
+		get_pid(pid);
 		spin_unlock_irqrestore(&tty->ctrl_lock, flags);
+		retval = __f_setown(filp, pid, type, 0);
+		put_pid(pid);
 		if (retval)
 			goto out;
 	} else {