[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1281477570-18944-46-git-send-email-gregkh@suse.de>
Date: Tue, 10 Aug 2010 14:59:08 -0700
From: Greg Kroah-Hartman <gregkh@...e.de>
To: linux-kernel@...r.kernel.org
Cc: Arnd Bergmann <arnd@...db.de>, Tony Luck <tony.luck@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
John Kacur <jkacur@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>, Ingo Molnar <mingo@...e.hu>,
Greg Kroah-Hartman <gregkh@...e.de>
Subject: [PATCH 46/68] tty: avoid recursive BTM in pty_close
From: Arnd Bergmann <arnd@...db.de>
When the console has been redirected, a hangup of the tty
will cause tty_release to be called under the big tty_mutex,
which leads to a deadlock because hangup is also called
under the BTM.
This moves the BTM deeper into the tty_hangup function so
we can close the redirected tty without holding the BTM.
In case of pty, we now need to drop the BTM before
calling tty_vhangup.
Signed-off-by: Arnd Bergmann <arnd@...db.de>
Acked-by: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Tony Luck <tony.luck@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: John Kacur <jkacur@...hat.com>
Cc: Al Viro <viro@...iv.linux.org.uk>
Cc: Ingo Molnar <mingo@...e.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
---
drivers/char/pty.c | 4 +++-
drivers/char/tty_io.c | 24 ++++++++++++------------
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/char/pty.c b/drivers/char/pty.c
index f2d7a76..ad46eae 100644
--- a/drivers/char/pty.c
+++ b/drivers/char/pty.c
@@ -62,7 +62,9 @@ static void pty_close(struct tty_struct *tty, struct file *filp)
if (tty->driver == ptm_driver)
devpts_pty_kill(tty->link);
#endif
- tty_vhangup_locked(tty->link);
+ tty_unlock();
+ tty_vhangup(tty->link);
+ tty_lock();
}
}
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index dcf7d36..4c4030c 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -471,7 +471,7 @@ void tty_wakeup(struct tty_struct *tty)
EXPORT_SYMBOL_GPL(tty_wakeup);
/**
- * do_tty_hangup - actual handler for hangup events
+ * __tty_hangup - actual handler for hangup events
* @work: tty device
*
* This can be called by the "eventd" kernel thread. That is process
@@ -492,7 +492,7 @@ EXPORT_SYMBOL_GPL(tty_wakeup);
* tasklist_lock to walk task list for hangup event
* ->siglock to protect ->signal/->sighand
*/
-void tty_vhangup_locked(struct tty_struct *tty)
+void __tty_hangup(struct tty_struct *tty)
{
struct file *cons_filp = NULL;
struct file *filp, *f = NULL;
@@ -512,10 +512,12 @@ void tty_vhangup_locked(struct tty_struct *tty)
}
spin_unlock(&redirect_lock);
+ tty_lock();
+
/* inuse_filps is protected by the single tty lock,
this really needs to change if we want to flush the
workqueue with the lock held */
- check_tty_count(tty, "do_tty_hangup");
+ check_tty_count(tty, "tty_hangup");
file_list_lock();
/* This breaks for file handles being sent over AF_UNIX sockets ? */
@@ -594,6 +596,9 @@ void tty_vhangup_locked(struct tty_struct *tty)
*/
set_bit(TTY_HUPPED, &tty->flags);
tty_ldisc_enable(tty);
+
+ tty_unlock();
+
if (f)
fput(f);
}
@@ -603,9 +608,7 @@ static void do_tty_hangup(struct work_struct *work)
struct tty_struct *tty =
container_of(work, struct tty_struct, hangup_work);
- tty_lock();
- tty_vhangup_locked(tty);
- tty_unlock();
+ __tty_hangup(tty);
}
/**
@@ -643,13 +646,12 @@ void tty_vhangup(struct tty_struct *tty)
printk(KERN_DEBUG "%s vhangup...\n", tty_name(tty, buf));
#endif
- tty_lock();
- tty_vhangup_locked(tty);
- tty_unlock();
+ __tty_hangup(tty);
}
EXPORT_SYMBOL(tty_vhangup);
+
/**
* tty_vhangup_self - process vhangup for own ctty
*
@@ -727,10 +729,8 @@ void disassociate_ctty(int on_exit)
if (tty) {
tty_pgrp = get_pid(tty->pgrp);
if (on_exit) {
- tty_lock();
if (tty->driver->type != TTY_DRIVER_TYPE_PTY)
- tty_vhangup_locked(tty);
- tty_unlock();
+ tty_vhangup(tty);
}
tty_kref_put(tty);
} else if (on_exit) {
--
1.7.2
--
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