public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, Greg KH <gregkh@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	John Kacur <jkacur@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>,
	Ingo Molnar <mingo@elte.hu>
Subject: [PATCH] tty: avoid recursive BTM in pty_close
Date: Fri, 18 Jun 2010 14:58:07 +0200	[thread overview]
Message-ID: <201006181458.07687.arnd@arndb.de> (raw)
In-Reply-To: <20100617220926.GC5345@nowhere>

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@arndb.de>
---
 drivers/char/pty.c    |    4 +++-
 drivers/char/tty_io.c |   24 ++++++++++++------------
 2 files changed, 15 insertions(+), 13 deletions(-)

---
On Friday 18 June 2010, Frederic Weisbecker wrote:
> > -             tty_vhangup_locked(tty->link);
> > +             unlock_kernel();
> > +             tty_vhangup(tty->link);
> > +             lock_kernel();
> 
> 
> 
> Don't you mean tty_unlock / tty_lock there?

Yes, thanks for catching this.

I did test this patch yesterday night (it was late) with CONFIG_TTY_MUTEX
disabled, as in Tony's configuration, but I did not realize that I
broke the other configuration in turn.

I'd like to get Alan's opinion on whether he considers the change in
pty.c safe.

diff --git a/drivers/char/pty.c b/drivers/char/pty.c
index c9af9ff..acff19f 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 5db354d..6bf6d36 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.0.4


  reply	other threads:[~2010-06-18 12:58 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-15 20:59 [PATCH v3 00/10] BKL conversion in tty layer Arnd Bergmann
2010-05-15 20:59 ` [PATCH 01/10] tty: replace BKL with a new tty_lock Arnd Bergmann
2010-05-15 20:59 ` [PATCH 02/10] tty: never hold BTM while getting tty_mutex Arnd Bergmann
2010-05-15 20:59 ` [PATCH 03/10] tty: fix console_sem lock order Arnd Bergmann
2010-05-15 20:59 ` [PATCH 04/10] cdc-acm: remove dead code Arnd Bergmann
2010-05-15 20:59 ` [PATCH 05/10] tty: introduce wait_event_interruptible_tty Arnd Bergmann
2010-05-15 20:59 ` [PATCH 06/10] tty: annotate tty_write_lock Arnd Bergmann
2010-05-15 20:59 ` [PATCH 07/10] tty: reorder ldisc locking Arnd Bergmann
2010-05-15 20:59 ` [PATCH 08/10] tty: untangle locking of wait_until_sent Arnd Bergmann
2010-05-16  3:12   ` Daniel K.
2010-05-15 20:59 ` [PATCH 09/10] tty: remove tty_lock_nested Arnd Bergmann
2010-05-15 20:59 ` [PATCH 10/10] tty: implement BTM as mutex instead of BKL Arnd Bergmann
2010-05-16  3:33   ` Daniel K.
2010-05-16 12:58     ` Arnd Bergmann
2010-05-17 13:41 ` [PATCH v3 00/10] BKL conversion in tty layer Alan Cox
2010-05-17 15:30   ` Greg KH
2010-05-17 18:30     ` Arnd Bergmann
2010-05-18  4:27       ` Greg KH
2010-05-18 21:52         ` Arnd Bergmann
2010-05-19  1:50           ` Greg KH
2010-05-22 13:54             ` Arnd Bergmann
2010-05-17 18:49   ` Arnd Bergmann
2010-06-17 19:13   ` Tony Luck
2010-06-17 19:40     ` Arnd Bergmann
2010-06-17 20:15       ` Tony Luck
2010-06-17 21:48         ` Arnd Bergmann
2010-06-17 22:09           ` Frederic Weisbecker
2010-06-18 12:58             ` Arnd Bergmann [this message]
2010-06-18 16:21               ` [PATCH] tty: avoid recursive BTM in pty_close Alan Cox
2010-06-18 16:52                 ` Tony Luck
2010-06-18 18:35                   ` Arnd Bergmann
2010-06-18 20:25                     ` Tony Luck
2010-06-19 12:32                       ` Arnd Bergmann
2010-06-19 20:29                         ` [PATCH] serial: revert "Use block_til_ready helper" Arnd Bergmann
2010-06-19 21:57                           ` Alan Cox
2010-06-20 20:54                             ` Arnd Bergmann
2010-06-21 14:13                               ` Alan Cox
2010-06-21 20:57                                 ` Arnd Bergmann
2010-06-21 20:58                                   ` Arnd Bergmann
2010-06-21 17:11                           ` Tony Luck
2010-06-22 23:01                           ` Greg KH
2010-06-28 17:17                     ` [PATCH] tty: avoid recursive BTM in pty_close Tony Luck
2010-06-28 19:03                       ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201006181458.07687.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@suse.de \
    --cc=jkacur@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox