linux.git/drivers/tty, branch v4.1-rc5 Linux kernel source tree Merge tag 'for-linus-4.1b-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip 2015-05-22T03:19:38+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-05-22T03:19:38+00:00 865d872280c848dc78b060088171724c3fb98bbb Pull two xen bugfixes from David Vrabel: - fix ARM build regression. - fix VIRQ_CONSOLE related oops. * tag 'for-linus-4.1b-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/events: don't bind non-percpu VIRQs with percpu chip xen/arm: Define xen_arch_suspend() 
Pull two xen bugfixes from David Vrabel:

 - fix ARM build regression.

 - fix VIRQ_CONSOLE related oops.

* tag 'for-linus-4.1b-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/events: don't bind non-percpu VIRQs with percpu chip
  xen/arm: Define xen_arch_suspend()
xen/events: don't bind non-percpu VIRQs with percpu chip 2015-05-19T18:55:36+00:00 David Vrabel david.vrabel@citrix.com 2015-05-19T17:40:49+00:00 77bb3dfdc0d554befad58fdefbc41be5bc3ed38a A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different VCPU than it is bound to. This can result in a race between handle_percpu_irq() and removing the action in __free_irq() because handle_percpu_irq() does not take desc->lock. The interrupt handler sees a NULL action and oopses. Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER). # cat /proc/interrupts | grep virq 40: 87246 0 xen-percpu-virq timer0 44: 0 0 xen-percpu-virq debug0 47: 0 20995 xen-percpu-virq timer1 51: 0 0 xen-percpu-virq debug1 69: 0 0 xen-dyn-virq xen-pcpu 74: 0 0 xen-dyn-virq mce 75: 29 0 xen-dyn-virq hvc_console Signed-off-by: David Vrabel <david.vrabel@citrix.com> Cc: <stable@vger.kernel.org> 
A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
VCPU than it is bound to.  This can result in a race between
handle_percpu_irq() and removing the action in __free_irq() because
handle_percpu_irq() does not take desc->lock.  The interrupt handler
sees a NULL action and oopses.

Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).

  # cat /proc/interrupts | grep virq
   40:      87246          0  xen-percpu-virq      timer0
   44:          0          0  xen-percpu-virq      debug0
   47:          0      20995  xen-percpu-virq      timer1
   51:          0          0  xen-percpu-virq      debug1
   69:          0          0   xen-dyn-virq      xen-pcpu
   74:          0          0   xen-dyn-virq      mce
   75:         29          0   xen-dyn-virq      hvc_console

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: <stable@vger.kernel.org>
Merge tag 'tty-4.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty 2015-05-17T04:10:05+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-05-17T04:10:05+00:00 dd8edd7e97bdc5d4b96e9f13c2fab3fdc6c9ca1f Pull tty/serial fixes from Greg KH: "Here's some TTY and serial driver fixes for reported issues. All of these have been in linux-next successfully" * tag 'tty-4.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: pty: Fix input race when closing tty/n_gsm.c: fix a memory leak when gsmtty is removed Revert "serial/amba-pl011: Leave the TX IRQ alone when the UART is not open" serial: omap: Fix error handling in probe earlycon: Revert log warnings 
Pull tty/serial fixes from Greg KH:
 "Here's some TTY and serial driver fixes for reported issues.

  All of these have been in linux-next successfully"

* tag 'tty-4.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  pty: Fix input race when closing
  tty/n_gsm.c: fix a memory leak when gsmtty is removed
  Revert "serial/amba-pl011: Leave the TX IRQ alone when the UART is not open"
  serial: omap: Fix error handling in probe
  earlycon: Revert log warnings
pty: Fix input race when closing 2015-05-10T17:26:37+00:00 Peter Hurley peter@hurleysoftware.com 2015-04-13T17:24:34+00:00 1a48632ffed61352a7810ce089dc5a8bcd505a60 A read() from a pty master may mistakenly indicate EOF (errno == -EIO) after the pty slave has closed, even though input data remains to be read. For example, pty slave | input worker | pty master | | | | n_tty_read() pty_write() | | input avail? no add data | | sleep schedule worker --->| | . |---> flush_to_ldisc() | . pty_close() | fill read buffer | . wait for worker | wakeup reader --->| . | read buffer full? |---> input avail ? yes |<--- yes - exit worker | copy 4096 bytes to user TTY_OTHER_CLOSED <---| |<--- kick worker | | **** New read() before worker starts **** | | n_tty_read() | | input avail? no | | TTY_OTHER_CLOSED? yes | | return -EIO Several conditions are required to trigger this race: 1. the ldisc read buffer must become full so the input worker exits 2. the read() count parameter must be >= 4096 so the ldisc read buffer is empty 3. the subsequent read() occurs before the kicked worker has processed more input However, the underlying cause of the race is that data is pipelined, while tty state is not; ie., data already written by the pty slave end is not yet visible to the pty master end, but state changes by the pty slave end are visible to the pty master end immediately. Pipeline the TTY_OTHER_CLOSED state through input worker to the reader. 1. Introduce TTY_OTHER_DONE which is set by the input worker when TTY_OTHER_CLOSED is set and either the input buffers are flushed or input processing has completed. Readers/polls are woken when TTY_OTHER_DONE is set. 2. Reader/poll checks TTY_OTHER_DONE instead of TTY_OTHER_CLOSED. 3. A new input worker is started from pty_close() after setting TTY_OTHER_CLOSED, which ensures the TTY_OTHER_DONE state will be set if the last input worker is already finished (or just about to exit). Remove tty_flush_to_ldisc(); no in-tree callers. Fixes: 52bce7f8d4fc ("pty, n_tty: Simplify input processing on final close") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96311 BugLink: http://bugs.launchpad.net/bugs/1429756 Cc: <stable@vger.kernel.org> # 3.19+ Reported-by: Andy Whitcroft <apw@canonical.com> Reported-by: H.J. Lu <hjl.tools@gmail.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
A read() from a pty master may mistakenly indicate EOF (errno == -EIO)
after the pty slave has closed, even though input data remains to be read.
For example,

       pty slave       |        input worker        |    pty master
                       |                            |
                       |                            |   n_tty_read()
pty_write()            |                            |     input avail? no
  add data             |                            |     sleep
  schedule worker  --->|                            |     .
                       |---> flush_to_ldisc()       |     .
pty_close()            |       fill read buffer     |     .
  wait for worker      |       wakeup reader    --->|     .
                       |       read buffer full?    |---> input avail ? yes
                       |<---   yes - exit worker    |     copy 4096 bytes to user
  TTY_OTHER_CLOSED <---|                            |<--- kick worker
                       |                            |

		                **** New read() before worker starts ****

                       |                            |   n_tty_read()
                       |                            |     input avail? no
                       |                            |     TTY_OTHER_CLOSED? yes
                       |                            |     return -EIO

Several conditions are required to trigger this race:
1. the ldisc read buffer must become full so the input worker exits
2. the read() count parameter must be >= 4096 so the ldisc read buffer
   is empty
3. the subsequent read() occurs before the kicked worker has processed
   more input

However, the underlying cause of the race is that data is pipelined, while
tty state is not; ie., data already written by the pty slave end is not
yet visible to the pty master end, but state changes by the pty slave end
are visible to the pty master end immediately.

Pipeline the TTY_OTHER_CLOSED state through input worker to the reader.
1. Introduce TTY_OTHER_DONE which is set by the input worker when
   TTY_OTHER_CLOSED is set and either the input buffers are flushed or
   input processing has completed. Readers/polls are woken when
   TTY_OTHER_DONE is set.
2. Reader/poll checks TTY_OTHER_DONE instead of TTY_OTHER_CLOSED.
3. A new input worker is started from pty_close() after setting
   TTY_OTHER_CLOSED, which ensures the TTY_OTHER_DONE state will be
   set if the last input worker is already finished (or just about to
   exit).

Remove tty_flush_to_ldisc(); no in-tree callers.

Fixes: 52bce7f8d4fc ("pty, n_tty: Simplify input processing on final close")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96311
BugLink: http://bugs.launchpad.net/bugs/1429756
Cc: <stable@vger.kernel.org> # 3.19+
Reported-by: Andy Whitcroft <apw@canonical.com>
Reported-by: H.J. Lu <hjl.tools@gmail.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty/n_gsm.c: fix a memory leak when gsmtty is removed 2015-05-10T17:25:32+00:00 Pan Xinhui xinhuix.pan@intel.com 2015-03-28T02:42:56+00:00 8f9cfeed3eae86c70d3b04445a6f2036b27b6304 when gsmtty_remove put dlci, it will cause memory leak if dlci->port's refcount is zero. So we do the cleanup work in .cleanup callback instead. dlci will be last put in two call chains. 1) gsmld_close -> gsm_cleanup_mux -> gsm_dlci_release -> dlci_put 2) gsmld_remove -> dlci_put so there is a race. the memory leak depends on the race. In call chain 2. we hit the memory leak. below comment tells. release_tty -> tty_driver_remove_tty -> gsmtty_remove -> dlci_put -> tty_port_destructor (WARN_ON(port->itty) and return directly) | tty->port->itty = NULL; | tty_kref_put ---> release_one_tty -> gsmtty_cleanup (added by our patch) So our patch fix the memory leak by doing the cleanup work after tty core did. Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com> Fixes: dfabf7ffa30585 Cc: stable <stable@vger.kernel.org> # 3.14+ Acked-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
when gsmtty_remove put dlci, it will cause memory leak if dlci->port's refcount is zero.
So we do the cleanup work in .cleanup callback instead.

dlci will be last put in two call chains.
1) gsmld_close -> gsm_cleanup_mux -> gsm_dlci_release -> dlci_put
2) gsmld_remove -> dlci_put
so there is a race. the memory leak depends on the race.

In call chain 2. we hit the memory leak. below comment tells.

release_tty -> tty_driver_remove_tty -> gsmtty_remove -> dlci_put -> tty_port_destructor (WARN_ON(port->itty) and return directly)
                         |
                tty->port->itty = NULL;
                         |
                tty_kref_put ---> release_one_tty -> gsmtty_cleanup (added by our patch)

So our patch fix the memory leak by doing the cleanup work after tty core did.

Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com>
Fixes: dfabf7ffa30585
Cc: stable <stable@vger.kernel.org> # 3.14+
Acked-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "serial/amba-pl011: Leave the TX IRQ alone when the UART is not open" 2015-05-09T16:36:36+00:00 Dave Martin Dave.Martin@arm.com 2015-05-08T13:07:50+00:00 ec61847855094d6f6144340b26f14203f25dd4e9 This reverts commit f2ee6dfa0e8597eea8b98d240b0033994e20d215. Jakub Kiciński observed that this patch can cause the pl011 driver to hang if if the only process with a pl011 port open is killed by a signal, pl011_shutdown() can get called with an arbitrary amount of data still in the FIFO. Calling _shutdown() with the TX FIFO non-empty is questionable behaviour and my itself be a bug. Since the affected patch was speculative anyway, and brings limited benefit, the simplest course is to remove the assumption that TXIS will always be left asserted after the port is shut down. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This reverts commit f2ee6dfa0e8597eea8b98d240b0033994e20d215.

Jakub Kiciński observed that this patch can cause the pl011
driver to hang if if the only process with a pl011 port open is
killed by a signal, pl011_shutdown() can get called with an
arbitrary amount of data still in the FIFO.

Calling _shutdown() with the TX FIFO non-empty is questionable
behaviour and my itself be a bug.

Since the affected patch was speculative anyway, and brings limited
benefit, the simplest course is to remove the assumption that TXIS
will always be left asserted after the port is shut down.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: omap: Fix error handling in probe 2015-05-08T12:20:50+00:00 Semen Protsenko semen.protsenko@globallogic.com 2015-04-30T15:35:27+00:00 66cf1d8473780fcb1a90e86fd19ba276520deb14 There is pm_qos_add_request() being executed on serial_omap_probe(), which stores "&up->pm_qos_request" from omap-serial driver to "pm_qos_array[PM_QOS_CPU_DMA_LATENCY]->constraints". If serial_omap_probe() fails after pm_qos_add_request() (e.g. on uart_add_one_port() call), pm_qos_array still keeping pm_qos_request struct from omap-serial driver, which is not valid anymore (since driver failed). This leads further to kernel crash on pm_qos_update_target(), executing from some completely different driver. We were observing this while trying to run audio playback while having one of omap-serial driver instances failed on uart_add_one_port() call: Unable to handle kernel paging request at virtual address fffffffc Backtrace: (plist_add) from (pm_qos_update_target) (pm_qos_update_target) from (pm_qos_add_request) (pm_qos_add_request) from (snd_pcm_hw_params) (snd_pcm_hw_params) from (snd_pcm_common_ioctl1) (snd_pcm_common_ioctl1) from (snd_pcm_playback_ioctl1) (snd_pcm_playback_ioctl1) from (snd_pcm_playback_ioctl) (snd_pcm_playback_ioctl) from (do_vfs_ioctl) (do_vfs_ioctl) from (SyS_ioctl) (SyS_ioctl) from (ret_fast_syscall) This patch adds pm_qos_remove_request() on fail path in serial_omap_probe() in order to fix this issue. While at it, free the wakeup settings on fail path as well, just like it's done in serial_omap_remove(). Signed-off-by: Semen Protsenko <semen.protsenko@globallogic.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
There is pm_qos_add_request() being executed on serial_omap_probe(),
which stores "&up->pm_qos_request" from omap-serial driver to
"pm_qos_array[PM_QOS_CPU_DMA_LATENCY]->constraints". If
serial_omap_probe() fails after pm_qos_add_request() (e.g. on
uart_add_one_port() call), pm_qos_array still keeping pm_qos_request
struct from omap-serial driver, which is not valid anymore (since driver
failed). This leads further to kernel crash on pm_qos_update_target(),
executing from some completely different driver.

We were observing this while trying to run audio playback while having
one of omap-serial driver instances failed on uart_add_one_port() call:
    Unable to handle kernel paging request at virtual address fffffffc
    Backtrace:
    (plist_add) from (pm_qos_update_target)
    (pm_qos_update_target) from (pm_qos_add_request)
    (pm_qos_add_request) from (snd_pcm_hw_params)
    (snd_pcm_hw_params) from (snd_pcm_common_ioctl1)
    (snd_pcm_common_ioctl1) from (snd_pcm_playback_ioctl1)
    (snd_pcm_playback_ioctl1) from (snd_pcm_playback_ioctl)
    (snd_pcm_playback_ioctl) from (do_vfs_ioctl)
    (do_vfs_ioctl) from (SyS_ioctl)
    (SyS_ioctl) from (ret_fast_syscall)

This patch adds pm_qos_remove_request() on fail path in
serial_omap_probe() in order to fix this issue. While at it, free the
wakeup settings on fail path as well, just like it's done in
serial_omap_remove().

Signed-off-by: Semen Protsenko <semen.protsenko@globallogic.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
earlycon: Revert log warnings 2015-05-08T12:20:50+00:00 Peter Hurley peter@hurleysoftware.com 2015-05-07T18:19:21+00:00 66c53aaa9c82766d4e9253748c6988441d8c2dc1 Log warnings meant to help diagnose problems setting up earlycon are reporting false positives for 'console='. Revert to the previous behavior which reported nothing. Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Robert Schwebel <r.schwebel@pengutronix.de> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Log warnings meant to help diagnose problems setting up earlycon
are reporting false positives for 'console='. Revert to the
previous behavior which reported nothing.

Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Robert Schwebel <r.schwebel@pengutronix.de>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'for-linus-4.1b-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip 2015-05-06T22:58:06+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-05-06T22:58:06+00:00 0e1dc4274828f64fcb56fc7b950acdc5ff7a395f Pull xen bug fixes from David Vrabel: - fix blkback regression if using persistent grants - fix various event channel related suspend/resume bugs - fix AMD x86 regression with X86_BUG_SYSRET_SS_ATTRS - SWIOTLB on ARM now uses frames <4 GiB (if available) so device only capable of 32-bit DMA work. * tag 'for-linus-4.1b-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen: Add __GFP_DMA flag when xen_swiotlb_init gets free pages on ARM hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests xen/events: Set irq_info->evtchn before binding the channel to CPU in __startup_pirq() xen/console: Update console event channel on resume xen/xenbus: Update xenbus event channel on resume xen/events: Clear cpu_evtchn_mask before resuming xen-pciback: Add name prefix to global 'permissive' variable xen: Suspend ticks on all CPUs during suspend xen/grant: introduce func gnttab_unmap_refs_sync() xen/blkback: safely unmap purge persistent grants 
Pull xen bug fixes from David Vrabel:

 - fix blkback regression if using persistent grants

 - fix various event channel related suspend/resume bugs

 - fix AMD x86 regression with X86_BUG_SYSRET_SS_ATTRS

 - SWIOTLB on ARM now uses frames <4 GiB (if available) so device only
   capable of 32-bit DMA work.

* tag 'for-linus-4.1b-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen: Add __GFP_DMA flag when xen_swiotlb_init gets free pages on ARM
  hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
  xen/events: Set irq_info->evtchn before binding the channel to CPU in __startup_pirq()
  xen/console: Update console event channel on resume
  xen/xenbus: Update xenbus event channel on resume
  xen/events: Clear cpu_evtchn_mask before resuming
  xen-pciback: Add name prefix to global 'permissive' variable
  xen: Suspend ticks on all CPUs during suspend
  xen/grant: introduce func gnttab_unmap_refs_sync()
  xen/blkback: safely unmap purge persistent grants
xen/console: Update console event channel on resume 2015-05-05T17:27:14+00:00 Boris Ostrovsky boris.ostrovsky@oracle.com 2015-04-29T21:10:14+00:00 b9d934f27c91b878c4b2e64299d6e419a4022f8d After a resume the hypervisor/tools may change console event channel number. We should re-query it. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: David Vrabel <david.vrabel@citrix.com> 
After a resume the hypervisor/tools may change console event
channel number. We should re-query it.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>