kernel/drivers/tty/tty_port.c, branch linux-4.1.y

Revert "tty_port: register tty ports with serdev bus"

2017-06-08T10:12:47Z

[ Upstream commit d3ba126a226a6b6da021ebfea444a2a807cde945 ] This reverts commit 8ee3fde047589dc9c201251f07d0ca1dc776feca. The new serdev bus hooked into the tty layer in tty_port_register_device() by registering a serdev controller instead of a tty device whenever a serdev client is present, and by deregistering the controller in the tty-port destructor. This is broken in several ways: Firstly, it leads to a NULL-pointer dereference whenever a tty driver later deregisters its devices as no corresponding character device will exist. Secondly, far from every tty driver uses tty-port refcounting (e.g. serial core) so the serdev devices might never be deregistered or deallocated. Thirdly, deregistering at tty-port destruction is too late as the underlying device and structures may be long gone by then. A port is not released before an open tty device is closed, something which a registered serdev client can prevent from ever happening. A driver callback while the device is gone typically also leads to crashes. Many tty drivers even keep their ports around until the driver is unloaded (e.g. serial core), something which even if a late callback never happens, leads to leaks if a device is unbound from its driver and is later rebound. The right solution here is to add a new tty_port_unregister_device() helper and to never call tty_device_unregister() whenever the port has been claimed by serdev, but since this requires modifying just about every tty driver (and multiple subsystems) it will need to be done incrementally. Reverting the offending patch is the first step in fixing the broken lifetime assumptions. A follow-up patch will add a new pair of tty-device registration helpers, which a vetted tty driver can use to support serdev (initially serial core). When every tty driver uses the serdev helpers (at least for deregistration), we can add serdev registration to tty_port_register_device() again. Note that this also fixes another issue with serdev, which currently allocates and registers a serdev controller for every tty device registered using tty_port_device_register() only to immediately deregister and deallocate it when the corresponding OF node or serdev child node is missing. This should be addressed before enabling serdev for hot-pluggable buses. Signed-off-by: Johan Hovold Reviewed-by: Rob Herring Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

tty_port: register tty ports with serdev bus

2017-06-08T10:12:47Z

[ Upstream commit 8ee3fde047589dc9c201251f07d0ca1dc776feca ] Register a serdev controller with the serdev bus when a tty_port is registered. This creates the serdev controller and create's serdev devices for any DT child nodes of the tty_port's parent (i.e. the UART device). Signed-off-by: Rob Herring Reviewed-By: Sebastian Reichel Tested-By: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

tty: Deletion of unnecessary checks before two function calls

2014-11-27T03:35:49Z

The functions put_device() and tty_kref_put() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Signed-off-by: Greg Kroah-Hartman

tty: Flush tty buffers after hardware shutdown

2014-11-06T22:57:27Z

The line discipline buffer and the tty buffers must be flushed again after hardware shutdown; otherwise, a brief window exists between the ldisc flush in tty_port_close_start() and the subsequent tty_port_shutdown(), during which more data could be received into the tty buffers. A racing open might then be able to receive data from the previous session. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: Move tty hung up check from port->lock critical section

2014-11-06T22:57:27Z

The port->lock does not protect the filp->f_op field; move the tty_hung_up_p() test outside the port->lock critical section in tty_port_close_start(). Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: Remove tty_hung_up_p() tests from tty drivers' open()

2014-07-10T23:06:49Z

Since at least before 2.6.30, it has not been possible to observe a hung up file pointer in a tty driver's open() method unless/until the driver open() releases the tty_lock() (eg., before blocking). This is because tty_open() adds the file pointer while holding the tty_lock() _and_ doesn't release the lock until after calling the tty driver's open() method. [ Before tty_lock(), this was lock_kernel(). ] Since __tty_hangup() first waits on the tty_lock() before enumerating and hanging up the open file pointers, either __tty_hangup() will wait for the tty_lock() or tty_open() will not yet have added the file pointer. For example, CPU 0 | CPU 1 | tty_open | __tty_hangup .. | .. tty_lock | .. tty_reopen | tty_lock / blocks .. | tty_add_file(tty, filp) | .. | tty->ops->open(tty, filp) | tty_port_open | tty_port_block_til_ready | .. | while (1) | .. | tty_unlock | / unblocks schedule | for each filp on tty->tty_files | f_ops = tty_hung_up_fops; | .. | tty_unlock tty_lock | .. | tty_unlock | Note that since tty_port_block_til_ready() and similar drop the tty_lock while blocking, when woken, the file pointer must then be tested for having been hung up. Also, fix bit-rotted drivers that used extra_count to track the port->count bump. CC: Mikael Starvik CC: Samuel Ortiz CC: "David S. Miller" Signed-off-by: Peter Hurley Acked-by: Jesper Nilsson Signed-off-by: Greg Kroah-Hartman

tty: Move tty->closing from port lock critical section

2014-07-10T23:06:48Z

tty->closing informs the line discipline that the hardware will be shutting down imminently, and to disable further input other than soft flow control (but to still allow additional output). However, the tty lock is the necessary lock for preventing concurrent changes to tty->closing. As shown by the call-tree audit [1] of functions that modify tty->closing, the tty lock is already held for those functions. [1] Call-tree audit of functions that modify tty->closing * does not include call tree to tty_port_close(), tty_port_close_start(), or tty_port_close_end() which is already documented in 'tty: Document locking for tty_port_close{,start,end}' that shows callers to those 3 functions hold the tty lock tty_release() tty->ops->close() --+ | __tty_hangup() | tty->ops->close() --+ | mp_close():drivers/staging/sb105x/sb_pci_mp.c dngc_tty_close():drivers/staging/dgnc/dgnc_tty.c dgap_tty_close():drivers/staging/dgap/dgap_tty.c dgrp_tty_close():drivers/staging/dgrp/dgrp_tty.c rp_close():drivers/tty/rocket.c hvsi_close():drivers/tty/hvc/hvsi.c rs_close():drivers/tty/serial/68328serial.c rs_close():drivers/tty/serial/crisv10.c uart_close():drivers/tty/serial/serial_core.c isdn_tty_close():drivers/isdn/i4l/isdn_tty.c tty3215_close():drivers/s390/char/con3215.c tty_open() tty_ldisc_setup() ----+ | __tty_hangup() | tty_ldisc_hangup() ---+ | tty_set_ldisc() --------+ tty_ldisc_restore() --+ | +- tty_ldisc_open() ld->ops->open() --+ | +- n_tty_open() Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: Document locking for tty_port_hangup()

2014-07-10T23:05:19Z

The tty lock is held when the tty driver's hangup() method is called (from the lone call-site, __tty_hangup()). The call-tree audit [1] of tty_port_hangup() is a closed graph of the callers of tty_port_hangup(); ie., all callers originate only from __tty_hangup(). Of these callers, none drop the tty lock prior to calling tty_port_hangup(). [1] Call-tree audit of tty_port_hangup() __tty_hangup() tty->ops->hangup() --+ | rs_hangup():arch/ia64/hp/sim/simserial.c line_hangup():arch/um/drivers/line.c gdm_tty_hangup():drivers/staging/gdm724x/gdm_tty.c fwtty_hangup():drivers/staging/fwserial/fwserial.c acm_tty_hangup():drivers/usb/class/cdc-acm.c serial_hangup():drivers/usb/serial/usb-serial.c ipoctal_hangup():drivers/ipack/devices/ipoctal.c cy_hangup():drivers/tty/cyclades.c isicom_hangup():drivers/tty/isicom.c rp_hangup():drivers/tty/rocket.c dashtty_hangup():drivers/tty/metag_da.c moxa_hangup():drivers/tty/moxa.c gsmtty_hangup():drivers/tty/n_gsm.c goldfish_tty_hangup():drivers/tty/goldfish.c ehv_bc_tty_hangup():drivers/tty/ehv_bytechan.c mxser_hangup():drivers/tty/mxser.c kgdb_nmi_tty_hangup():drivers/tty/serial/kgdb_nmi.c ifx_spi_hangup():drivers/tty/serial/ifx6x60.c ntty_hangup():drivers/tty/nozomi.c capinc_tty_hangup():drivers/isdn/capi/capi.c mgslpc_hangup():drivers/char/pcmcia/synclink_cs.c sdio_uart_hangup():drivers/mmc/card/sdio_uart.c rfcomm_tty_hangup():net/bluetooth/rfcomm/tty.c | +- tty_port_hangup() Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: Document locking for tty_port_block_til_ready()

2014-07-10T23:05:19Z

The tty lock is held when the tty driver's open() method is called (from tty_open()). The call-tree audit [1] of tty_port_block_til_ready() is a closed graph of the callers of tty_port_block_til_ready(); ie., all callers originate only from tty_open(). Of these callers, none drop the tty lock. Also, document tty_port_block_til_ready() may drop and reacquire the tty lock when blocking, which means the tty or tty_port may have changed state. [1] Call-tree audit of tty_port_block_til_ready() * does not include call tree of tty_port_open() which is already documented in 'tty: Document locking from tty_port_open()' tty_open() tty->ops->open() --+ | cy_open():drivers/tty/cyclades.c rp_open():drivers/tty/rocket.c rs_open():drivers/tty/amiserial.c moxa_open():drivers/tty/moxa.c gsmtty_open():drivers/tty/n_gsm.c rs_open():drivers/tty/serial/68328serial.c uart_open():drivers/tty/serial/serial_core.c isdn_tty_open():drivers/isdn/i4l/isdn_tty.c mgslpc_open():drivers/char/pcmcia/synclink_cs.c | +- tty_port_block_til_ready() Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: Document locking for tty_port_open()

2014-07-10T23:05:19Z

The tty lock is held when the tty driver's open method is called (from the lone call-site, tty_open()). The call-tree audit [1] of tty_port_open() is a closed graph of the callers of tty_port_open(); ie., all callers originate from only tty_open(). Of these callers, none drop the tty lock. Also, document that tty_port_block_til_ready() may drop and reacquire the tty lock when blocking, which means the tty or tty_port may have changed state. [1] Call-tree audit of tty_port_open() tty_open() tty->ops->open() --+ | rs_open():arch/ia64/hp/sim/simserial.c *line_open():arch/um/drivers/line.c gdm_tty_open():drivers/staging/gdm724x/gdm_tty.c fwtty_open():drivers/staging/fwserial/fwserial.c acm_tty_open():drivers/usb/class/cdc-acm.c serial_open():drivers/usb/serial/usb-serial.c pti_tty_driver_open():drivers/misc/pti.c ipoctal_open():drivers/ipack/devices/ipoctal.c isicom_open():drivers/tty/isicom.c dashtty_open():drivers/tty/metag_da.c goldfish_tty_open():drivers/tty/goldfish.c ehv_bc_tty_open():drivers/tty/ehv_bytechan.c mxser_open():drivers/tty/mxser.c kgdb_nmi_tty_open():drivers/tty/serial/kgdb_nmi.c ifx_spi_open():drivers/tty/serial/ifx6x60.c smd_tty_open():drivers/tty/serial/msm_smd_tty.c ntty_open():drivers/tty/nozomi.c capinc_tty_open():drivers/isdn/capi/capi.c tpk_open():drivers/char/ttyprintk.c sdio_uart_open():drivers/mmc/card/sdio_uart.c rfcomm_tty_open():net/bluetooth/rfcomm/tty.c | +- tty_port_open() * line_open() is the .open method for 2 um drivers declared in ./arch/um/drivers/stdio_console.c and in ./arch/um/drivers/ssl.c, and not called directly Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman