linux-stable.git/drivers/tty, branch v3.0.28

serial: sh-sci: fix a race of DMA submit_tx on transfer

2012-04-02T16:27:22+00:00

commit 49d4bcaddca977fffdea8b0b71f6e5da96dac78e upstream.

When DMA is enabled, sh-sci transfer begins with
 uart_start()
  sci_start_tx()
    if (cookie_tx < 0) schedule_work()
Then, starts DMA when wq scheduled, -- (A)
 process_one_work()
  work_fn_rx()
   cookie_tx = desc->submit_tx()
And finishes when DMA transfer ends, -- (B)
 sci_dma_tx_complete()
  async_tx_ack()
  cookie_tx = -EINVAL
  (possible another schedule_work())

This A to B sequence is not reentrant, since controlling variables
(for example, cookie_tx above) are not queues nor lists. So, they
must be invoked as A B A B..., otherwise results in kernel crash.

To ensure the sequence, sci_start_tx() seems to test if cookie_tx < 0
(represents "not used") to call schedule_work().
But cookie_tx will not be set (to a cookie, also means "used") until
in the middle of work queue scheduled function work_fn_tx().

This gap between the test and set allows the breakage of the sequence
under the very frequently call of uart_start().
Another gap between async_tx_ack() and another schedule_work() results
in the same issue, too.

This patch introduces a new condition "cookie_tx == 0" just to mark
it is "busy" and assign it within spin-locked region to fill the gaps.

Signed-off-by: Takashi Yoshii 
Reviewed-by: Guennadi Liakhovetski 
Signed-off-by: Paul Mundt 
Signed-off-by: Greg Kroah-Hartman

TTY: Wrong unicode value copied in con_set_unimap()

2012-04-02T16:26:53+00:00

commit 4a4c61b7ce26bfc9d49ea4bd121d52114bad9f99 upstream.

Bugzilla 40012: PIO_UNIMAP bug: error updating Unicode-to-font map
https://bugzilla.kernel.org/show_bug.cgi?id=40012

The unicode font map for the virtual console is a 32x32x64 table which
allocates rows dynamically as entries are added.  The unicode value
increases sequentially and should count all entries even in empty
rows.  The defect is when copying the unicode font map in con_set_unimap(),
the unicode value is not incremented properly.  The wrong unicode value
is entered in the new font map.

Signed-off-by: Liz Clark 
Signed-off-by: Greg Kroah-Hartman

tty: moxa: fix bit test in moxa_start()

2012-04-02T16:26:53+00:00

commit 58112dfbfe02d803566a2c6c8bd97b5fa3c62cdc upstream.

This is supposed to be doing a shift before the comparison instead of
just doing a bitwise AND directly.  The current code means the start()
just returns without doing anything.

Signed-off-by: Dan Carpenter 
Acked-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

drivers/tty/vt/vt_ioctl.c: fix KDFONTOP 32bit compatibility layer

2012-02-13T19:06:05+00:00

commit cbcb8346054073d000ecac324763372d6abd44ac upstream.

KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland
with a 64bit kernel if the font width is not 8.

This is because of the setting of the KD_FONT_FLAG_OLD flag, which makes
con_font_get return EIO in such case.

This flag should *not* be set for KDFONTOP, since it's actually the whole
point of this flag (see comment in con_font_set for instance).

Signed-off-by: Samuel Thibault 
Reviewed-by: Arnd Bergmann 
Cc: Arthur Taylor 
Cc: Jiri Slaby 
Cc: Jiri Olsa 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

jsm: Fixed EEH recovery error

2012-02-03T17:19:00+00:00

commit 26aa38cafae0dbef3b2fe75ea487c83313c36d45 upstream.

There was an error on the jsm driver that would cause it to be unable to
recover after a second error is detected.

At the first error, the device recovers properly:

[72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0
[72521.485695] EEH: This PCI device has failed 1 times in the last hour:
...
[72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm
[72532.105689] jsm: Port 3 added

However, at the second error, it cascades until EEH disables the device:

[72631.229549] Call Trace:
...
[72641.725687] jsm: Port 3 added
[72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0
[72641.725698] EEH: This PCI device has failed 3 times in the last hour:

It was caused because the PCI state was not being saved after the first
restore. Therefore, at the second recovery the PCI state would not be
restored.

Signed-off-by: Lucas Kannebley Tavares 
Signed-off-by: Breno Leitao 
Acked-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Greg Kroah-Hartman

serial: amba-pl011: lock console writes against interrupts

2012-02-03T17:19:00+00:00

commit ef605fdb33883d687cff5ba75095a91b313b4966 upstream.

Protect against pl011_console_write() and the interrupt for
the console UART running concurrently on different CPUs.

Otherwise the console_write could spin for a long time
waiting for the UART to become not busy, while the other
CPU continuously services UART interrupts and keeps the
UART busy.

The checks for sysrq and oops_in_progress are taken
from 8250.c.

Signed-off-by: Rabin Vincent 
Reviewed-by: Srinidhi Kasagar 
Reviewed-by: Bibek Basu 
Reviewed-by: Shreshtha Kumar Sahu 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

TTY: fix UV serial console regression

2012-02-03T17:19:00+00:00

commit 0eee50af5b13e00b3fb7a5fe8480419a71b8235d upstream.

Commit 74c2107759d (serial: Use block_til_ready helper) and its fixup
3f582b8c110 (serial: fix termios settings in open) introduced a
regression on UV systems. The serial eventually freezes while being
used. It's completely unpredictable and sometimes needs a heap of
traffic to happen first.

To reproduce this, yast installation was used as it turned out to be
pretty reliable in reproducing. Especially during installation process
where one doesn't have an SSH daemon running. And no monitor as the HW
is completely headless. So this was fun to find. Given the machine
doesn't boot on vanilla before 2.6.36 final. (And the commits above
are older.)

Unless there is some bad race in the code, the hardware seems to be
pretty broken. Otherwise pure MSR read should not cause such a bug,
or?

So to prevent the bug, revert to the old behavior. I.e. read modem
status only if we really have to -- for non-CLOCAL set serials.
Non-CLOCAL works on this hardware OK, I tried. See? I don't.

And document that shit.

Signed-off-by: Jiri Slaby 
References: https://lkml.org/lkml/2011/12/6/573
References: https://bugzilla.novell.com/show_bug.cgi?id=718518
Signed-off-by: Greg Kroah-Hartman

atmel_serial: fix spinlock lockup in RS485 code

2012-01-12T19:35:07+00:00

commit dbf1115d3f8c7052788aa4e6e46abd27f3b3eeba upstream.

Patch to fix a spinlock lockup in the driver that sometimes happens when the
tasklet starts.

Signed-off-by: Claudio Scordino 
Signed-off-by: Dave Bender 
Tested-by: Dave Bender 
Acked-by: Nicolas Ferre 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

TTY: ldisc, wait for ldisc infinitely in hangup

2011-11-26T17:09:58+00:00

commit 0c73c08ec73dbe080b9ec56696ee21d32754d918 upstream.

For /dev/console case, we do not kill all ldisc users. It's due to
redirected_tty_write test in __tty_hangup. In that case there still
might be a process waiting e.g. in n_tty_read for input.

We wait for such processes to disappear. The problem is that we use a
timeout. After this timeout, we continue closing the ldisc and start
freeing tty resources. It obviously leads to crashes when the other
process is woken.

So to fix this, we wait infinitely before reiniting the ldisc. (The
tiocsetd remains untouched -- times out after 5s.)

This is nicely reproducible with this run from shell:
  exec 0<>/dev/console 1<>/dev/console 2<>/dev/console
and stopping a getty like:
  systemctl stop serial-getty@ttyS0.service

The crash proper may be produced only under load or with constified
timing the same as for 92f6fa09b.

Signed-off-by: Jiri Slaby 
Cc: Dave Young 
Cc: Dave Jones 
Cc: Ben Hutchings 
Cc: Dmitriy Matrosov 
Cc: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

TTY: ldisc, move wait idle to caller

2011-11-26T17:09:58+00:00

commit 300420722e0734a4254f3b634e0f82664495d210 upstream.

It is the only place where reinit is called from. And we really need
to wait for the old ldisc to go once. Actually this is the place where
the waiting originally was (before removed and re-added later).

This will make the fix in the following patch easier to implement.

Signed-off-by: Jiri Slaby 
Cc: Dave Young 
Cc: Dave Jones 
Cc: Ben Hutchings 
Cc: Dmitriy Matrosov 
Cc: Alan Cox 
Signed-off-by: Greg Kroah-Hartman