BMC/Intel-BMC/linux.git/drivers/tty/tty_port.c, branch dev-4.4

tty: Abstract tty buffer work

2015-10-18T04:32:21+00:00

Introduce API functions to restart and cancel tty buffer work, rather than manipulate buffer work directly. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: Remove tty_port::close_wait

2015-10-18T04:11:29+00:00

With the removal of tty_wait_until_sent_from_close(), tty drivers no longer wait during open for parallel closes to complete (instead, the tty core waits before calling the driver open() method). Thus, the close_wait waitqueue is no longer used for waiting. Remove struct tty_port::close_wait. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: Remove ASYNC_CLOSING checks in open()/hangup() methods

2015-10-18T04:11:29+00:00

Since at least before 2.6.30, tty drivers that do not drop the tty lock while closing cannot observe ASYNC_CLOSING set while holding the tty lock; this includes the tty driver's open() and hangup() methods, since the tty core calls these methods holding the tty lock. For these drivers, waiting for ASYNC_CLOSING to clear while opening is not required, since this condition cannot occur. Similarly, even when the open() method drops and reacquires the tty lock after blocking, ASYNC_CLOSING cannot be set (again, for drivers that do not drop the tty lock while closing). Now that tty port drivers no longer drop the tty lock while closing (since 'tty: Remove tty_wait_until_sent_from_close()'), the same conditions apply: waiting for ASYNC_CLOSING to clear while opening is not required, nor is re-checking ASYNC_CLOSING after dropping and reacquiring the tty lock while blocking (eg., in *_block_til_ready()). Note: The ASYNC_CLOSING flag state is still maintained since several bitrotting drivers use it for (dubious) other purposes. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: Remove tty_wait_until_sent_from_close()

2015-10-18T04:11:29+00:00

tty_wait_until_sent_from_close() drops the tty lock while waiting for the tty driver to finish sending previously accepted data (ie., data remaining in its write buffer and transmit fifo). tty_wait_until_sent_from_close() was added by commit a57a7bf3fc7e ("TTY: define tty_wait_until_sent_from_close") to prevent the entire tty subsystem from being unable to open new ttys while waiting for one tty to close while output drained. However, since commit 0911261d4cb6 ("tty: Don't take tty_mutex for tty count changes"), holding a tty lock while closing does not prevent other ttys from being opened/closed/hung up, but only prevents lifetime event changes for the tty under lock. Holding the tty lock while waiting for output to drain does prevent parallel non-blocking opens (O_NONBLOCK) from advancing or returning while the tty lock is held. However, all parallel opens _already_ block even if the tty lock is dropped while closing and the parallel open advances. Blocking in open has been in mainline since at least 2.6.29 (see tty_port_block_til_ready(); note the test for O_NONBLOCK is _after_ the wait while ASYNC_CLOSING). IOW, before this patch a non-blocking open will sleep anyway for the _entire_ duration of a parallel hardware shutdown, and when it wakes, the error return will cause a release of its tty, and it will restart with a fresh attempt to open. Similarly with a blocking open that is already waiting; when it's woken, the hardware shutdown has already completed to ASYNC_INITIALIZED is not set, which forces a release and restart as well. So, holding the tty lock across the _entire_ close (which is what this patch does), even while waiting for output to drain, is equivalent to the current outcome wrt parallel opens. Cc: Alan Cox Cc: David Laight CC: Arnd Bergmann CC: Karsten Keil CC: linuxppc-dev@lists.ozlabs.org Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: Deletion of unnecessary checks before two function calls

2014-11-27T03:35:49+00:00

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:27+00:00

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:27+00:00

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:49+00:00

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:48+00:00

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:19+00:00

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