[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20120524145052.4698.17929.stgit@bob.linux.org.uk>
Date: Thu, 24 May 2012 15:51:15 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: linux-kernel@...r.kernel.org, davej@...hat.com
Subject: [PATCH] pty: Fix lock inversion
From: Alan Cox <alan@...ux.intel.com>
The ptmx_open path takes the tty and devpts locks in the wrong order
because tty_init_dev locks and returns a locked tty. As far as I can tell
this is actually safe anyway because the tty being returned is new so
nobody can get a reference to lock it at this point.
However we don't even need the devpts lock at this point, it's only held as
a byproduct of the way the locks were pushe down.
Signed-off-by: Alan Cox <alan@...ux.intel.com>
---
drivers/tty/pty.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 59af394..65c7c62 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -633,7 +633,6 @@ static int ptmx_open(struct inode *inode, struct file *filp)
mutex_unlock(&devpts_mutex);
mutex_lock(&tty_mutex);
- mutex_lock(&devpts_mutex);
tty = tty_init_dev(ptm_driver, index);
if (IS_ERR(tty)) {
@@ -643,7 +642,6 @@ static int ptmx_open(struct inode *inode, struct file *filp)
/* The tty returned here is locked so we can safely
drop the mutex */
- mutex_unlock(&devpts_mutex);
mutex_unlock(&tty_mutex);
set_bit(TTY_PTY_LOCK, &tty->flags); /* LOCK THE SLAVE */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists