summaryrefslogtreecommitdiffstats
path: root/lib/decompress_bunzip2.c
diff options
context:
space:
mode:
authorLinus Torvalds2009-10-04 06:44:21 +0200
committerLinus Torvalds2009-10-04 06:44:21 +0200
commit0b5759c654e74c8dc317ea2c6b3a7476160f688a (patch)
tree50de6ba41dcc19cb76c8a35408b7cc1ba80d2e41 /lib/decompress_bunzip2.c
parentMerge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiw... (diff)
downloadkernel-qcow2-linux-0b5759c654e74c8dc317ea2c6b3a7476160f688a.tar.gz
kernel-qcow2-linux-0b5759c654e74c8dc317ea2c6b3a7476160f688a.tar.xz
kernel-qcow2-linux-0b5759c654e74c8dc317ea2c6b3a7476160f688a.zip
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 'lib/decompress_bunzip2.c')
0 files changed, 0 insertions, 0 deletions