<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/tty/vt, branch v3.6</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/tty/vt?h=v3.6</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/tty/vt?h=v3.6'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-07-26T20:37:02Z</updated>
<entry>
<title>vt: fix race in vt_waitactive()</title>
<updated>2012-07-26T20:37:02Z</updated>
<author>
<name>Rabin Vincent</name>
<email>rabin.vincent@stericsson.com</email>
</author>
<published>2012-05-21T08:08:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a7b12929be6cc55eab2dac3330fa9f5984e12dda'/>
<id>urn:sha1:a7b12929be6cc55eab2dac3330fa9f5984e12dda</id>
<content type='text'>
pm_restore_console() is called from the suspend/resume path, and this
calls vt_move_to_console(), which calls vt_waitactive().

There's a race in this path which causes the process which requests the
suspend to sleep indefinitely waiting for an event which already
happened:

P1                                      P2
 vt_move_to_console()
  set_console()
    schedule_console_callback()
  vt_waitactive()
    check n == fg_console +1
                                       console_callback()
                                         switch_screen()
                                         vt_event_post() // no waiters

    vt_event_wait() // forever

Fix the race by ensuring we're registered for the event before we check
if it's already completed.

Signed-off-by: Rabin Vincent &lt;rabin.vincent@stericsson.com&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'x86-platform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2012-05-23T18:16:40Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-05-23T18:16:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=44bc40e1489622234169786b0ad5a1f4a01e1090'/>
<id>urn:sha1:44bc40e1489622234169786b0ad5a1f4a01e1090</id>
<content type='text'>
Pull x86 platform changes from Ingo Molnar:
 "This tree includes assorted platform driver updates and a preparatory
  series for a platform with custom DMA remapping semantics (sta2x11 I/O
  hub)."

* 'x86-platform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/vsmp: Fix number of CPUs when vsmp is disabled
  keyboard: Use BIOS Keyboard variable to set Numlock
  x86/olpc/xo1/sci: Report RTC wakeup events
  x86/olpc/xo1/sci: Produce wakeup events for buttons and switches
  x86, platform: Initial support for sta2x11 I/O hub
  x86: Introduce CONFIG_X86_DMA_REMAP
  x86-32: Introduce CONFIG_X86_DEV_DMA_OPS
</content>
</entry>
<entry>
<title>Merge tag 'tty-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty</title>
<updated>2012-05-22T23:12:24Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-05-22T23:12:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=94b5aff4c6f72fee6b0f49d49e4fa8b204e8ded9'/>
<id>urn:sha1:94b5aff4c6f72fee6b0f49d49e4fa8b204e8ded9</id>
<content type='text'>
Pull TTY updates from Greg Kroah-Hartman:
 "Here's the big TTY/serial driver pull request for the 3.5-rc1 merge
  window.

  Nothing major in here, just lots of incremental changes from Alan and
  Jiri reworking some tty core things to behave better and to get a more
  solid grasp on some of the nasty tty locking issues.

  There are a few tty and serial driver updates in here as well.

  All of this has been in the linux-next releases for a while with no
  problems.

  Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;"

* tag 'tty-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (115 commits)
  serial: bfin_uart: Make MMR access compatible with 32 bits bf609 style controller.
  serial: bfin_uart: RTS and CTS MMRs can be either 16-bit width or 32-bit width.
  serial: bfin_uart: narrow the reboot condition in DMA tx interrupt
  serial: bfin_uart: Adapt bf5xx serial driver to bf60x serial4 controller.
  Revert "serial_core: Update buffer overrun statistics."
  tty: hvc_xen: NULL dereference on allocation failure
  tty: Fix LED error return
  tty: Allow uart_register/unregister/register
  tty: move global ldisc idle waitqueue to the individual ldisc
  serial8250-em: Add DT support
  serial8250-em: clk_get() IS_ERR() error handling fix
  serial_core: Update buffer overrun statistics.
  tty: drop the pty lock during hangup
  cris: fix missing tty arg in wait_event_interruptible_tty call
  tty/amiserial: Add missing argument for tty_unlock()
  tty_lock: Localise the lock
  pty: Lock the devpts bits privately
  tty_lock: undo the old tty_lock use on the ctty
  serial8250-em: Emma Mobile UART driver V2
  Add missing call to uart_update_timeout()
  ...
</content>
</entry>
<entry>
<title>tty: Fix LED error return</title>
<updated>2012-05-14T17:43:24Z</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-05-14T13:41:31Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=eea41aee2bfad4cf5c84e1cab8aa068c66206651'/>
<id>urn:sha1:eea41aee2bfad4cf5c84e1cab8aa068c66206651</id>
<content type='text'>
3.4-rc introduced a regression when setting the LEDS. We do the right thing
but then return an error code.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=43144
Reported-by: Christian Casteyde
Signed-off-by: Alan Cox &lt;alan@linux/intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>tty: Fix LED error return</title>
<updated>2012-05-14T16:04:28Z</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-05-14T13:41:31Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=05f843b5d3406c29c8af7d1eb39ea9143b21d6dc'/>
<id>urn:sha1:05f843b5d3406c29c8af7d1eb39ea9143b21d6dc</id>
<content type='text'>
3.4-rc introduced a regression when setting the LEDS. We do the right thing
but then return an error code.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=43144
Reported-by: Christian Casteyde
Signed-off-by: Alan Cox &lt;alan@linux/intel.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>keyboard: Use BIOS Keyboard variable to set Numlock</title>
<updated>2012-05-08T21:19:41Z</updated>
<author>
<name>Joshua Cov</name>
<email>joshuacov@googlemail.com</email>
</author>
<published>2012-04-13T19:08:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b2d0b7a061bfddd27155c7dcd53f365d9dc0c7c3'/>
<id>urn:sha1:b2d0b7a061bfddd27155c7dcd53f365d9dc0c7c3</id>
<content type='text'>
The PC BIOS does provide a NUMLOCK flag containing the desired state
of this LED. This patch sets the current state according to the data
in the bios.

[ hpa: fixed __weak declaration without definition, changed "inline"
  to "static inline" ]

Signed-Off-By: Joshua Cov &lt;joshuacov@googlemail.com&gt;
Link: http://lkml.kernel.org/r/CAKL7Q7rvq87TNS1T_Km8fW_5OzS%2BSbYazLXKxW-6ztOxo3zorg@mail.gmail.com
Acked-by: Alan Cox &lt;alan@lxorguk.ukuu.org.uk&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
</content>
</entry>
<entry>
<title>vt: Fix deadlock on scroll-lock</title>
<updated>2012-05-01T18:01:28Z</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-05-01T15:12:19Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=84f904ecd3aa2ccb5779b815b69c1cb592f07bb5'/>
<id>urn:sha1:84f904ecd3aa2ccb5779b815b69c1cb592f07bb5</id>
<content type='text'>
Fixing the locking accidentally replaced a race in the scroll
lock handling with a deadlock. Turn it back into a race for
now.

The basic problem is that there are two paths into the tty
stop/start helpers. One via the tty layer ^S/^Q handling
where we need to take the kbd_event_lock and one via the
special keyboard handler for fn_hold where we already hold
it. Probably we need to split out into a separate LED lock
but for now just go back to the race as it's a bit close
to release.

Reported-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>vt: push the tty_lock down into the map handling</title>
<updated>2012-04-24T23:14:14Z</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-04-24T10:06:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5d1a33fa5573702394a4d09a9872f3f930c06d58'/>
<id>urn:sha1:5d1a33fa5573702394a4d09a9872f3f930c06d58</id>
<content type='text'>
When we do this it becomes clear the lock we should be holding is the vc
lock, and in fact many of our other helpers are properly invoked this way.

We don't at this point guarantee not to race the keyboard code but the results
of that appear harmless and that was true before we started as well.

We now have no users of tty_lock in the console driver...

Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge 3.4-rc3 into tty-next</title>
<updated>2012-04-18T22:57:31Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2012-04-18T22:57:31Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=665ab0f3c8b8f86bb77b25285ac93870c7054d63'/>
<id>urn:sha1:665ab0f3c8b8f86bb77b25285ac93870c7054d63</id>
<content type='text'>
This allows us to pick up some changes needed for other serial patches.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty/vt: handle bad user buffer in {G,P}IO_CMAP ioctl</title>
<updated>2012-04-09T19:10:23Z</updated>
<author>
<name>Michael Gehring</name>
<email>mg@ebfe.org</email>
</author>
<published>2012-03-21T00:26:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=871bdea6f8c64517635bec352b8bec6b72a26d80'/>
<id>urn:sha1:871bdea6f8c64517635bec352b8bec6b72a26d80</id>
<content type='text'>
set_get_cmap() ignored the result of {get,put}_user(), causing ioctl(vt,
{G,P}IO_CMAP, 0xdeadbeef) to silently fail.

Another side effect of this: calling the PIO_CMAP ioctl with an invalid
buffer would zero the default colormap and the palette for all vts (all
colors set to black).

Leave the default colormap intact and return -EFAULT when
reading/writing to the userspace buffer fails.

Signed-off-by: Michael Gehring &lt;mg@ebfe.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
