TTY fix for 3.4-rc5

This is a deadlock bugfix that was easy to hit, and that the vt layer lock
 rework got wrong, so it reverts the logic back to the way it was in 3.3 and
 earlier kernels to prevent problems.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (GNU/Linux)
 
 iEYEABECAAYFAk+hlr4ACgkQMUfUDdst+ynGqwCfeaot2snAEoWi1qp1pU+4cAJn
 8gwAoLaO//pVnVmUIplPMRtFr3tuUN/h
 =z8wN
 -----END PGP SIGNATURE-----

Merge tag 'tty-3.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

Pull a TTY fix from Greg Kroah-Hartman:
 "This is a deadlock bugfix that was easy to hit, and that the vt layer
  lock rework got wrong, so it reverts the logic back to the way it was
  in 3.3 and earlier kernels to prevent problems."

* tag 'tty-3.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  vt: Fix deadlock on scroll-lock
This commit is contained in:
Linus Torvalds 2012-05-02 13:47:49 -07:00
commit c89ff23960
1 changed files with 19 additions and 7 deletions

View File

@ -1085,15 +1085,21 @@ void vt_set_led_state(int console, int leds)
*
* Handle console start. This is a wrapper for the VT layer
* so that we can keep kbd knowledge internal
*
* FIXME: We eventually need to hold the kbd lock here to protect
* the LED updating. We can't do it yet because fn_hold calls stop_tty
* and start_tty under the kbd_event_lock, while normal tty paths
* don't hold the lock. We probably need to split out an LED lock
* but not during an -rc release!
*/
void vt_kbd_con_start(int console)
{
struct kbd_struct * kbd = kbd_table + console;
unsigned long flags;
spin_lock_irqsave(&kbd_event_lock, flags);
/* unsigned long flags; */
/* spin_lock_irqsave(&kbd_event_lock, flags); */
clr_vc_kbd_led(kbd, VC_SCROLLOCK);
set_leds();
spin_unlock_irqrestore(&kbd_event_lock, flags);
/* spin_unlock_irqrestore(&kbd_event_lock, flags); */
}
/**
@ -1102,22 +1108,28 @@ void vt_kbd_con_start(int console)
*
* Handle console stop. This is a wrapper for the VT layer
* so that we can keep kbd knowledge internal
*
* FIXME: We eventually need to hold the kbd lock here to protect
* the LED updating. We can't do it yet because fn_hold calls stop_tty
* and start_tty under the kbd_event_lock, while normal tty paths
* don't hold the lock. We probably need to split out an LED lock
* but not during an -rc release!
*/
void vt_kbd_con_stop(int console)
{
struct kbd_struct * kbd = kbd_table + console;
unsigned long flags;
spin_lock_irqsave(&kbd_event_lock, flags);
/* unsigned long flags; */
/* spin_lock_irqsave(&kbd_event_lock, flags); */
set_vc_kbd_led(kbd, VC_SCROLLOCK);
set_leds();
spin_unlock_irqrestore(&kbd_event_lock, flags);
/* spin_unlock_irqrestore(&kbd_event_lock, flags); */
}
/*
* This is the tasklet that updates LED state on all keyboards
* attached to the box. The reason we use tasklet is that we
* need to handle the scenario when keyboard handler is not
* registered yet but we already getting updates form VT to
* registered yet but we already getting updates from the VT to
* update led state.
*/
static void kbd_bh(unsigned long dummy)