Now that tty_debug() macro uses pr_debug(), the function name can
be printed when using dynamic debug; printing the function name within
the format string is redundant.
Remove the __func__ parameter and print specifier from the format string.
Add context to messages for when the function name is not printed by
dynamic debug, or when dynamic debug is not enabled.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With the refactor of 'locked' from parameter to local,
it's now obvious locked cannot be NULL. Remove entire conditional.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add tty as parameter to unset_locked_termios() and extract former
parameters, termios and locked, as locals.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty_name no longer uses the buf parameter, so remove it along with all
the 64 byte stack buffers that used to be passed in.
Mostly generated by the coccinelle script
@depends on patch@
identifier buf;
constant C;
expression tty;
@@
- char buf[C];
<+...
- tty_name(tty, buf)
+ tty_name(tty)
...+>
allmodconfig compiles, so I'm fairly confident the stack buffers
weren't used for other purposes as well.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently tty_wait_until_sent may take up to twice as long as the
requested timeout while waiting for driver and hardware buffers to
drain.
Fix this by taking the remaining number of jiffies after waiting for
driver buffers to drain into account so that the timeout actually
becomes a maximum timeout as it is documented to be.
Note that this specifically implies tighter timings when closing a port
as a consequence of actually honouring the port closing-wait setting
for drivers relying on tty_wait_until_sent_from_close (e.g. via
tty_port_close_start).
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
infinite timeout (0) would be passed to the underlying tty-driver's
wait_until_sent-operation as a negative timeout (-1), causing it to
return immediately.
This manifests itself for example as tcdrain() returning immediately,
drivers not honouring the drain flags when setting terminal attributes,
or even dropped data on close as a requested infinite closing-wait
timeout would be ignored.
The first symptom was reported by Asier LLANO who noted that tcdrain()
returned prematurely when using the ftdi_sio usb-serial driver.
Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the
underlying tty driver.
Note that the serial-core wait_until_sent-implementation is not affected
by this bug due to a lucky chance (comparison to an unsigned maximum
timeout), and neither is the cyclades one that had an explicit check for
negative timeouts, but all other tty drivers appear to be affected.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org> # v2.6.12
Reported-by: ZIV-Asier Llano Palacios <asier.llano@cgglobal.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty_set_termios() is an internal helper intended for file scope use.
UART drivers which are capable of driving the RTS pin must
properly handle the tiocmset() method, regardless of termios settings.
A failure to do so is a UART driver bug and should be fixed there.
Do not use this interface to workaround UART driver bugs.
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: <linux-bluetooth@vger.kernel.org>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The use of older function ptr calling style, (*fn)(), makes static
analysis more error-prone; replace with modern fn() style.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Packet mode is unique to the pty driver; move the packet mode state
change code from the generic tty ioctl handler to the pty driver.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The pty master's termios should never be set; currently, all code
paths which call the driver's set_termios() method ensure that the
pty slave's termios is being set.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
While transmitting a START/STOP char for tcflow(TCION/TCIOFF), prevent
a termios change. Otherwise, a garbage in-band flow control char
may be sent, if the termios change overlaps the transmission setup.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Relocate the file-scope function, send_prio_char(), as a global
helper tty_send_xchar(). Remove the global declarations for
tty_write_lock()/tty_write_unlock(), as these are file-scope only now.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use newly-introduced tty->flow_lock to serialize updates to
tty->flow_stopped (via tcflow()) and with concurrent tty flow
control changes from other sources.
Merge the storage for ->stopped and ->flow_stopped, now that both
flags are serialized by ->flow_lock.
The padding bits are necessary to force the compiler to allocate the
type specified; otherwise, gcc will ignore the type specifier and
allocate the minimum number of bytes necessary to store the bitfield.
In turn, this would allow Alpha EV4 and EV5 cpus to corrupt adjacent
byte storage because those cpus use RMW to store byte and short data.
gcc versions < 4.7.2 will also corrupt storage adjacent to bitfields
smaller than unsigned long on ia64, ppc64, hppa64 and sparc64, thus
requiring more than unsigned int storage (which would otherwise be
sufficient to workaround the Alpha non-atomic byte/short storage problem).
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 'e7f3880cd9b98c5bf9391ae7acdec82b75403776'
tty: Fix recursive deadlock in tty_perform_flush()
introduced a regression where tcflush() does not generate
SIGTTOU for background process groups.
Make sure ioctl(TCFLSH) calls tty_check_change() when
invoked from the line discipline.
Cc: stable@vger.kernel.org # v3.10+
Reported-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No tty driver modifies termios during throttle() or unthrottle().
Therefore, only read safety is required.
However, tty_throttle_safe and tty_unthrottle_safe must still be
mutually exclusive; introduce throttle_mutex for that purpose.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty_perform_flush() can deadlock when called while holding
a line discipline reference. By definition, all ldisc drivers
hold a ldisc reference, so calls originating from ldisc drivers
must not block for a ldisc reference.
The deadlock can occur when:
CPU 0 | CPU 1
|
tty_ldisc_ref(tty) |
.... | <line discipline halted>
tty_ldisc_ref_wait(tty) |
|
CPU 0 cannot progess because it cannot obtain an ldisc reference
with the line discipline has been halted (thus no new references
are granted).
CPU 1 cannot progress because an outstanding ldisc reference
has not been released.
An in-tree call-tree audit of tty_perform_flush() [1] shows 5
ldisc drivers calling tty_perform_flush() indirectly via
n_tty_ioctl_helper() and 2 ldisc drivers calling directly.
A single tty driver safely uses the function.
[1]
Recursive usage:
/* These functions are line discipline ioctls and thus
* recursive wrt line discipline references */
tty_perform_flush() - ./drivers/tty/tty_ioctl.c
n_tty_ioctl_helper()
hci_uart_tty_ioctl(default) - drivers/bluetooth/hci_ldisc.c (N_HCI)
n_hdlc_tty_ioctl(default) - drivers/tty/n_hdlc.c (N_HDLC)
gsmld_ioctl(default) - drivers/tty/n_gsm.c (N_GSM0710)
n_tty_ioctl(default) - drivers/tty/n_tty.c (N_TTY)
gigaset_tty_ioctl(default) - drivers/isdn/gigaset/ser-gigaset.c (N_GIGASET_M101)
ppp_synctty_ioctl(TCFLSH) - drivers/net/ppp/pps_synctty.c
ppp_asynctty_ioctl(TCFLSH) - drivers/net/ppp/ppp_async.c
Non-recursive use:
tty_perform_flush() - drivers/tty/tty_ioctl.c
ipw_ioctl(TCFLSH) - drivers/tty/ipwireless/tty.c
/* This function is a tty i/o ioctl method, which
* is invoked by tty_ioctl() */
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The warning is there since 2.1.69 and we have not seen anybody
reporting it in the past decade. Remove the warning now.
tty_get_baud_rate can now be inline. This gives us one less
EXPORT_SYMBOL.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The tty driver can become stuck throttled due to race conditions
between throttle and unthrottle, when the decision to throttle
or unthrottle is conditional. The following example helps to
illustrate the race:
CPU 0 | CPU 1
|
if (condition A) |
| <processing such that A not true>
| if (!condition A)
| unthrottle()
throttle() |
|
Note the converse is also possible; ie.,
CPU 0 | CPU 1
|
| if (!condition A)
<processing such that A true> |
if (condition A) |
throttle() |
| unthrottle()
|
Add new throttle/unthrottle functions based on the familiar model
of task state and schedule/wake. For example,
while (1) {
tty_set_flow_change(tty, TTY_THROTTLE_SAFE);
if (!condition)
break;
if (!tty_throttle_safe(tty))
break;
}
__tty_set_flow_change(tty, 0);
In this example, if an unthrottle occurs after the condition is
evaluated but before tty_throttle_safe(), then tty_throttle_safe()
will return non-zero, looping and forcing the re-evaluation of
condition.
Reported-by: Vincent Pillet <vincentx.pillet@intel.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley
Rasmus Villemoes
Frederic Danis
Johan Hovold
Matthias Brugger
Jiri Slaby