linux-toradex.git/drivers/tty/tty_buffer.c, branch v3.14.57

Staging: speakup: Update __speakup_paste_selection() tty (ab)usage to match vt

2014-06-11T18:54:12+00:00

commit 28a821c306889b9f2c3fff49abedc9b2c743eb73 upstream.

This function is largely a duplicate of paste_selection() in
drivers/tty/vt/selection.c, but with its own selection state.  The
speakup selection mechanism should really be merged with vt.

For now, apply the changes from 'TTY: vt, fix paste_selection ldisc
handling', 'tty: Make ldisc input flow control concurrency-friendly',
and 'tty: Fix unsafe vt paste_selection()'.

References: https://bugs.debian.org/735202
References: https://bugs.debian.org/744015
Reported-by: Paul Gevers 
Reported-and-tested-by: Jarek Czekalski 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

tty: Fix lockless tty buffer race

2014-05-13T11:32:47+00:00

commit 62a0d8d7c2b29f92850e4ee3c38e5dfd936e92b2 upstream.

Commit 6a20dbd6caa2358716136144bf524331d70b1e03,
"tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc"
correctly identifies an unsafe race condition between
__tty_buffer_request_room() and flush_to_ldisc(), where the consumer
flush_to_ldisc() prematurely advances the head before consuming the
last of the data committed. For example:

           CPU 0                     |            CPU 1
__tty_buffer_request_room            | flush_to_ldisc
  ...                                |   ...
                                     |   count = head->commit - head->read
  n = tty_buffer_alloc()             |
  b->commit = b->used                |
  b->next = n                        |
                                     |   if (!count)                /* T */
                                     |     if (head->next == NULL)  /* F */
                                     |     buf->head = head->next

In this case, buf->head has been advanced but head->commit may have
been updated with a new value.

Instead of reintroducing an unnecessary lock, fix the race locklessly.
Read the commit-next pair in the reverse order of writing, which guarantees
the commit value read is the latest value written if the head is
advancing.

Reported-by: Manfred Schlaegl 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: Fix low_latency BUG

2014-04-27T00:19:04+00:00

commit a9c3f68f3cd8d55f809fbdb0c138ed061ea1bd25 upstream.

The user-settable knob, low_latency, has been the source of
several BUG reports which stem from flush_to_ldisc() running
in interrupt context. Since 3.12, which added several sleeping
locks (termios_rwsem and buf->lock) to the input processing path,
the frequency of these BUG reports has increased.

Note that changes in 3.12 did not introduce this regression;
sleeping locks were first added to the input processing path
with the removal of the BKL from N_TTY in commit
a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc,
'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
and later in commit 38db89799bdf11625a831c5af33938dcb11908b6,
'tty: throttling race fix'. Since those changes, executing
flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.

However, since most devices do not validate if the low_latency
setting is appropriate for the context (process or interrupt) in
which they receive data, some reports are due to misconfiguration.
Further, serial dma devices for which dma fails, resort to
interrupt receiving as a backup without resetting low_latency.

Historically, low_latency was used to force wake-up the reading
process rather than wait for the next scheduler tick. The
effect was to trim multiple milliseconds of latency from
when the process would receive new data.

Recent tests [1] have shown that the reading process now receives
data with only 10's of microseconds latency without low_latency set.

Remove the low_latency rx steering from tty_flip_buffer_push();
however, leave the knob as an optional hint to drivers that can
tune their rx fifos and such like. Cleanup stale code comments
regarding low_latency.

[1] https://lkml.org/lkml/2014/2/20/434

"Yay.. thats an annoying historical pain in the butt gone."
	-- Alan Cox

Reported-by: Beat Bolli 
Reported-by: Pavel Roskin 
Acked-by: David Sterba 
Cc: Grant Edwards 
Cc: Stanislaw Gruszka 
Cc: Hal Murray 
Signed-off-by: Peter Hurley 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

tty: delete non-required instances of include

2014-01-08T01:05:21+00:00

None of these files are actually using any __init type directives
and hence don't need to include .  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

Signed-off-by: Paul Gortmaker 
Signed-off-by: Greg Kroah-Hartman

tty: Halve flip buffer GFP_ATOMIC memory consumption

2013-12-09T19:09:24+00:00

tty flip buffers use GFP_ATOMIC allocations for received data
which is to be processed by the line discipline. For each byte
received, an extra byte is used to indicate the error status of
that byte.

Instead, if the received data is error-free, encode the entire
buffer without status bytes.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: Fix stale tty_buffer_flush() comment

2013-12-09T01:10:26+00:00

Commit d7a68be4f265be10e24be931c257af30ca55566b,
'tty: Only perform flip buffer flush from tty_buffer_flush()',
removed buffer flushing from flush_to_ldisc().

Fix function header comment which describes the former behavior.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

staging/fwserial: Rip out rx buffering

2013-12-09T01:03:03+00:00

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: Remove tty_prepare_flip_string_flags()

2013-12-09T00:57:38+00:00

There is no in-tree user of tty_prepare_flip_string_flags(); remove.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: Rename tty buffer memory_used field

2013-12-09T00:57:38+00:00

Trim up the memory_used field name to mem_used.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: Enable configurable tty flip buffer limit

2013-12-09T00:57:38+00:00

Allow driver to configure its maximum flip buffer memory
consumption/limit. This is necessary for very-high speed line
rates (in excess of 10MB/sec) because the flip buffers can
be saturated before the line discipline has a chance to
throttle the input.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman