summaryrefslogtreecommitdiffstats
path: root/arch/um
diff options
context:
space:
mode:
authorAlan Cox <alan@linux.intel.com>2009-06-11 12:44:17 +0100
committerLinus Torvalds <torvalds@linux-foundation.org>2009-06-11 08:50:59 -0700
commit38db89799bdf11625a831c5af33938dcb11908b6 (patch)
treec50eff175df0fbe9270ef461962030d6bdfad674 /arch/um
parent5b0ed5263cb089500052f8c1ab6e0706bebf0d83 (diff)
downloadlinux-38db89799bdf11625a831c5af33938dcb11908b6.tar.bz2
tty: throttling race fix
The tty throttling code can race due to the lock drops. It takes very high loads but this has been observed and verified by Rob Duncan. The basic problem is that on an SMP box we can go CPU #1 CPU #2 need to throttle ? suppose we should buffer space cleared are we throttled yes ? - unthrottle call throttle method This changeet take the termios lock to protect against this. The termios lock isn't the initial obvious candidate but many implementations of throttle methods already need to poke around their own termios structures (and nobody really locks them against a racing change of flow control). This does mean that anyone who is setting tty->low_latency = 1 and then calling tty_flip_buffer_push from their unthrottle method is going to end up collapsing in a pile of locks. However we've removed all the known bogus users of low_latency = 1 and such use isn't safe anyway for other reasons so catching it would be an improvement. Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/um')
0 files changed, 0 insertions, 0 deletions