aboutsummaryrefslogtreecommitdiff
path: root/Documentation/i2c/upgrading-clients
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2009-10-03 21:44:21 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2009-10-03 21:44:21 -0700
commit0b5759c654e74c8dc317ea2c6b3a7476160f688a (patch)
tree50de6ba41dcc19cb76c8a35408b7cc1ba80d2e41 /Documentation/i2c/upgrading-clients
parentf0a221ef47df3cdde2123fe75ce3b61bb7df656d (diff)
tty: Avoid dropping ldisc_mutex over hangup tty re-initialization
A couple of people have hit the WARN_ON() in drivers/char/tty_io.c, tty_open() that is unhappy about seeing the tty line discipline go away during the tty hangup. See for example http://bugzilla.kernel.org/show_bug.cgi?id=14255 and the reason is that we do the tty_ldisc_halt() outside the ldisc_mutex in order to be able to flush the scheduled work without a deadlock with vhangup_work. However, it turns out that we can solve this particular case by - using "cancel_delayed_work_sync()" in tty_ldisc_halt(), which waits for just the particular work, rather than synchronizing with any random outstanding pending work. This won't deadlock, since the buf.work we synchronize with doesn't care about the ldisc_mutex, it just flushes the tty ldisc buffers. - realize that for this particular case, we don't need to wait for any hangup work, because we are inside the hangup codepaths ourselves. so as a result we can just drop the flush_scheduled_work() entirely, and then move the tty_ldisc_halt() call to inside the mutex. That way we never expose the partially torn down ldisc state to tty_open(), and hold the ldisc_mutex over the whole sequence. Reported-by: Ingo Molnar <mingo@elte.hu> Reported-by: Heinz Diehl <htd@fancy-poultry.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/i2c/upgrading-clients')
0 files changed, 0 insertions, 0 deletions