linux-stable.git/drivers/tty/tty_ldisc.c, branch linux-3.8.y

tty: don't deadlock while flushing workqueue

2013-04-17T04:48:30+00:00

commit 852e4a8152b427c3f318bb0e1b5e938d64dcdc32 upstream.

Since commit 89c8d91e31f2 ("tty: localise the lock") I see a dead lock
in one of my dummy_hcd + g_nokia test cases. The first run was usually
okay, the second often resulted in a splat by lockdep and the third was
usually a dead lock.
Lockdep complained about tty->hangup_work and tty->legacy_mutex taken
both ways:
| ======================================================
| [ INFO: possible circular locking dependency detected ]
| 3.7.0-rc6+ #204 Not tainted
| -------------------------------------------------------
| kworker/2:1/35 is trying to acquire lock:
|  (&tty->legacy_mutex){+.+.+.}, at: [] tty_lock_nested+0x36/0x80
|
| but task is already holding lock:
|  ((&tty->hangup_work)){+.+...}, at: [] process_one_work+0x124/0x5e0
|
| which lock already depends on the new lock.
|
| the existing dependency chain (in reverse order) is:
|
| -> #2 ((&tty->hangup_work)){+.+...}:
|        [] lock_acquire+0x84/0x190
|        [] flush_work+0x3d/0x240
|        [] tty_ldisc_flush_works+0x16/0x30
|        [] tty_ldisc_release+0x21/0x70
|        [] tty_release+0x35c/0x470
|        [] __fput+0xd8/0x270
|        [] ____fput+0xd/0x10
|        [] task_work_run+0xb9/0xf0
|        [] do_notify_resume+0x51/0x80
|        [] work_notifysig+0x35/0x3b
|
| -> #1 (&tty->legacy_mutex/1){+.+...}:
|        [] lock_acquire+0x84/0x190
|        [] mutex_lock_nested+0x6c/0x2f0
|        [] tty_lock_nested+0x36/0x80
|        [] tty_lock_pair+0x29/0x70
|        [] tty_release+0x118/0x470
|        [] __fput+0xd8/0x270
|        [] ____fput+0xd/0x10
|        [] task_work_run+0xb9/0xf0
|        [] do_notify_resume+0x51/0x80
|        [] work_notifysig+0x35/0x3b
|
| -> #0 (&tty->legacy_mutex){+.+.+.}:
|        [] __lock_acquire+0x1189/0x16a0
|        [] lock_acquire+0x84/0x190
|        [] mutex_lock_nested+0x6c/0x2f0
|        [] tty_lock_nested+0x36/0x80
|        [] tty_lock+0xf/0x20
|        [] __tty_hangup+0x54/0x410
|        [] do_tty_hangup+0x12/0x20
|        [] process_one_work+0x1a3/0x5e0
|        [] worker_thread+0x119/0x3a0
|        [] kthread+0x94/0xa0
|        [] ret_from_kernel_thread+0x1b/0x28
|
|other info that might help us debug this:
|
|Chain exists of:
|  &tty->legacy_mutex --> &tty->legacy_mutex/1 --> (&tty->hangup_work)
|
| Possible unsafe locking scenario:
|
|       CPU0                    CPU1
|       ----                    ----
|  lock((&tty->hangup_work));
|                               lock(&tty->legacy_mutex/1);
|                               lock((&tty->hangup_work));
|  lock(&tty->legacy_mutex);
|
| *** DEADLOCK ***

Before the path mentioned tty_ldisc_release() look like this:

|	tty_ldisc_halt(tty);
|	tty_ldisc_flush_works(tty);
|	tty_lock();

As it can be seen, it first flushes the workqueue and then grabs the
tty_lock. Now we grab the lock first:

|	tty_lock_pair(tty, o_tty);
|	tty_ldisc_halt(tty);
|	tty_ldisc_flush_works(tty);

so lockdep's complaint seems valid.

The earlier version of this patch took the ldisc_mutex since the other
user of tty_ldisc_flush_works() (tty_set_ldisc()) did this.
Peter Hurley then said that it is should not be requried. Since it
wasn't done earlier, I dropped this part.
The code under tty_ldisc_kill() was executed earlier with the tty lock
taken so it is taken again.

I was able to reproduce the deadlock on v3.8-rc1, this patch fixes the
problem in my testcase. I didn't notice any problems so far.

Signed-off-by: Sebastian Andrzej Siewior 
Cc: Alan Cox 
Cc: Peter Hurley 
Cc: Bryan O'Donoghue 
Signed-off-by: Greg Kroah-Hartman

tty: Use raw spin lock to protect TTY ldisc administration

2012-10-24T18:37:02+00:00

The global "normal" spin lock that guards the line discipline
administration is replaced by a raw spin lock. On a PREEMPT_RT system this
prevents unwanted scheduling overhead around the line discipline administration.

On a 200 MHz AT91SAM9261 processor setup this fixes about 100us of scheduling
overhead on a TTY read or write call.

Signed-off-by: Ivo Sieben 
Signed-off-by: Greg Kroah-Hartman

TTY: move tty buffers to tty_port

2012-10-22T23:58:28+00:00

So this is it. The big step why we did all the work over the past
kernel releases. Now everything is prepared, so nothing protects us
from doing that big step.

           |  |            \  \ nnnn/^l      |  |
           |  |             \  /     /       |  |
           |  '-,.__   =>    \/   ,-`    =>  |  '-,.__
           | O __.´´)        (  .`           | O __.´´)
            ~~~   ~~          ``              ~~~   ~~
The buffers are now in the tty_port structure and we can start
teaching the buffer helpers (insert char/string, flip etc.) to use
tty_port instead of tty_struct all around.

Signed-off-by: Jiri Slaby 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

TTY: ldisc, wait for idle ldisc in release

2012-10-22T23:50:53+00:00

We reintroduced tty_ldisc_wait_idle in 100eeae2c5c (TTY: restore
tty_ldisc_wait_idle) and used in set_ldisc. Then we added it also to
the hangup path in 92f6fa09bd453 (TTY: ldisc, do not close until there
are readers). And we noted that there is one more path:
~   Before 65b770468e98 tty_ldisc_wait_idle was called also from
~   tty_ldisc_release. It is called from tty_release, so I don't think
~   we need to restore that one.

Well, I was wrong. There might still be holders of an ldisc
reference. Not from userspace, but drivers. If they take a reference
and a user closes the device immediately after that, we have a
problem. ldisc is halted and closed by TTY, but the driver still may
call some ldisc's operation and cause a crash.

So restore the tty_ldisc_wait_idle call also to the third location
where it was before 65b770468e98 (tty-ldisc: turn ldisc user count
into a proper refcount). Now we should be safe with respect to the
ldisc reference counting as all* tty_ldisc_close paths are safely
called with reference count of one.

* Not the one in tty_ldisc_setup's fail path. But that is called
  before the first open finishes. So userspace does not see it yet.
  Even thought the driver is given the TTY already via ->install, it
  should not take a reference to the ldisc yet. If some driver is to
  do this, we should put one tty_ldisc_wait_idle also in the setup.

Signed-off-by: Jiri Slaby 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq

2012-10-02T16:54:49+00:00

Pull workqueue changes from Tejun Heo:
 "This is workqueue updates for v3.7-rc1.  A lot of activities this
  round including considerable API and behavior cleanups.

   * delayed_work combines a timer and a work item.  The handling of the
     timer part has always been a bit clunky leading to confusing
     cancelation API with weird corner-case behaviors.  delayed_work is
     updated to use new IRQ safe timer and cancelation now works as
     expected.

   * Another deficiency of delayed_work was lack of the counterpart of
     mod_timer() which led to cancel+queue combinations or open-coded
     timer+work usages.  mod_delayed_work[_on]() are added.

     These two delayed_work changes make delayed_work provide interface
     and behave like timer which is executed with process context.

   * A work item could be executed concurrently on multiple CPUs, which
     is rather unintuitive and made flush_work() behavior confusing and
     half-broken under certain circumstances.  This problem doesn't
     exist for non-reentrant workqueues.  While non-reentrancy check
     isn't free, the overhead is incurred only when a work item bounces
     across different CPUs and even in simulated pathological scenario
     the overhead isn't too high.

     All workqueues are made non-reentrant.  This removes the
     distinction between flush_[delayed_]work() and
     flush_[delayed_]_work_sync().  The former is now as strong as the
     latter and the specified work item is guaranteed to have finished
     execution of any previous queueing on return.

   * In addition to the various bug fixes, Lai redid and simplified CPU
     hotplug handling significantly.

   * Joonsoo introduced system_highpri_wq and used it during CPU
     hotplug.

  There are two merge commits - one to pull in IRQ safe timer from
  tip/timers/core and the other to pull in CPU hotplug fixes from
  wq/for-3.6-fixes as Lai's hotplug restructuring depended on them."

Fixed a number of trivial conflicts, but the more interesting conflicts
were silent ones where the deprecated interfaces had been used by new
code in the merge window, and thus didn't cause any real data conflicts.

Tejun pointed out a few of them, I fixed a couple more.

* 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: (46 commits)
  workqueue: remove spurious WARN_ON_ONCE(in_irq()) from try_to_grab_pending()
  workqueue: use cwq_set_max_active() helper for workqueue_set_max_active()
  workqueue: introduce cwq_set_max_active() helper for thaw_workqueues()
  workqueue: remove @delayed from cwq_dec_nr_in_flight()
  workqueue: fix possible stall on try_to_grab_pending() of a delayed work item
  workqueue: use hotcpu_notifier() for workqueue_cpu_down_callback()
  workqueue: use __cpuinit instead of __devinit for cpu callbacks
  workqueue: rename manager_mutex to assoc_mutex
  workqueue: WORKER_REBIND is no longer necessary for idle rebinding
  workqueue: WORKER_REBIND is no longer necessary for busy rebinding
  workqueue: reimplement idle worker rebinding
  workqueue: deprecate __cancel_delayed_work()
  workqueue: reimplement cancel_delayed_work() using try_to_grab_pending()
  workqueue: use mod_delayed_work() instead of __cancel + queue
  workqueue: use irqsafe timer for delayed_work
  workqueue: clean up delayed_work initializers and add missing one
  workqueue: make deferrable delayed_work initializer names consistent
  workqueue: cosmetic whitespace updates for macro definitions
  workqueue: deprecate system_nrt[_freezable]_wq
  workqueue: deprecate flush[_delayed]_work_sync()
  ...

workqueue: deprecate flush[_delayed]_work_sync()

2012-08-20T21:51:24+00:00

flush[_delayed]_work_sync() are now spurious.  Mark them deprecated
and convert all users to flush[_delayed]_work().

If you're cc'd and wondering what's going on: Now all workqueues are
non-reentrant and the regular flushes guarantee that the work item is
not pending or running on any CPU on return, so there's no reason to
use the sync flushes at all and they're going away.

This patch doesn't make any functional difference.

Signed-off-by: Tejun Heo 
Cc: Russell King 
Cc: Paul Mundt 
Cc: Ian Campbell 
Cc: Jens Axboe 
Cc: Mattia Dongili 
Cc: Kent Yoder 
Cc: David Airlie 
Cc: Jiri Kosina 
Cc: Karsten Keil 
Cc: Bryan Wu 
Cc: Benjamin Herrenschmidt 
Cc: Alasdair Kergon 
Cc: Mauro Carvalho Chehab 
Cc: Florian Tobias Schandinat 
Cc: David Woodhouse 
Cc: "David S. Miller" 
Cc: linux-wireless@vger.kernel.org
Cc: Anton Vorontsov 
Cc: Sangbeom Kim 
Cc: "James E.J. Bottomley" 
Cc: Greg Kroah-Hartman 
Cc: Eric Van Hensbergen 
Cc: Takashi Iwai 
Cc: Steven Whitehouse 
Cc: Petr Vandrovec 
Cc: Mark Fasheh 
Cc: Christoph Hellwig 
Cc: Avi Kivity

tty: localise the lock

2012-08-10T19:55:47+00:00

The termios and other changes mean the other protections needed on the driver
tty arrays should be adequate. Turn it all back on.

This contains pieces folded in from the fixes made to the original patches

| From: Geert Uytterhoeven 	(fix m68k)
| From: Paul Gortmaker 	(fix cris)
| From: Jiri Kosina 			(lockdep)
| From: Eric Dumazet 		(lockdep)

Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

tty: Fix race in tty release

2012-07-27T18:55:59+00:00

Ian Abbott found that the tty layer would explode with the right set of
parallel open and close operations. This is because we race in the
handling of tty->drivers->termios[].

Correct this by
	Making tty_ldisc_release behave like nromal code (takes the lock,
			does stuff, drops the lock)
	Drop the tty lock earlier in tty_ldisc_release
	Taking the tty mutex around the driver->termios update in all cases
	Adding a WARN_ON to catch future screwups.

I also forgot to clean up the pty resources properly. With a pty pair we
need to pull both halves out of the tables.

Signed-off-by: Alan Cox 
Tested-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

tty ldisc: Close/Reopen race prevention should check the proper flag

2012-07-26T20:37:06+00:00

Commit acfa747b introduced the TTY_HUPPING flag to distinguish
closed TTY from currently closing ones. The test in tty_set_ldisc
still remained pointing at the old flag. This causes pppd to
sometimes lapse into uninterruptible sleep when killed and
restarted.

Signed-off-by: Shachar Shemesh 
Signed-off-by: Greg Kroah-Hartman

tty: move the termios object into the tty

2012-07-16T20:00:41+00:00

This will let us sort out a whole pile of tty related races. The
alternative would be to keep points and refcount the termios objects.
However
1. They are tiny anyway
2. Many devices don't use the stored copies
3. We can remove a pty special case

Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman