linux-toradex.git/drivers/tty/tty_buffer.c, branch v4.11-rc1

tty_port: Add port client functions

2017-02-03T09:17:02+00:00

Introduce a client (upward direction) operations struct for tty_port
clients. Initially supported operations are for receiving data and write
wake-up. This will allow for having clients other than an ldisc.

Convert the calls to the ldisc to use the client ops as the default
operations.

Signed-off-by: Rob Herring 
Reviewed-By: Sebastian Reichel 
Tested-By: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

tty: constify tty_ldisc_receive_buf buffer pointer

2017-01-19T16:22:34+00:00

This is needed to work with the client operations which uses const ptrs.

Really, the flags pointer could be const, too, but this would be a tree
wide fix.

Signed-off-by: Rob Herring 
Reviewed-by: Andy Shevchenko 
Reviewed-By: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

Fix OpenSSH pty regression on close

2016-05-01T20:22:54+00:00

OpenSSH expects the (non-blocking) read() of pty master to return
EAGAIN only if it has received all of the slave-side output after
it has received SIGCHLD. This used to work on pre-3.12 kernels.

This fix effectively forces non-blocking read() and poll() to
block for parallel i/o to complete for all ttys. It also unwinds
these changes:

1) f8747d4a466ab2cafe56112c51b3379f9fdb7a12
   tty: Fix pty master read() after slave closes

2) 52bce7f8d4fc633c9a9d0646eef58ba6ae9a3b73
   pty, n_tty: Simplify input processing on final close

3) 1a48632ffed61352a7810ce089dc5a8bcd505a60
   pty: Fix input race when closing

Inspired by analysis and patch from Marc Aurele La France 

Reported-by: Volth 
Reported-by: Marc Aurele La France 
BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52
BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492
Signed-off-by: Brian Bloniarz 
Reviewed-by: Peter Hurley 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: Unify receive_buf() code paths

2016-01-28T22:13:44+00:00

Instead of two distinct code branches for receive_buf() handling,
use tty_ldisc_receive_buf() as the single code path.

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

tty: Fix GPF in flush_to_ldisc()

2015-12-13T07:05:28+00:00

A line discipline which does not define a receive_buf() method can
can cause a GPF if data is ever received [1]. Oddly, this was known
to the author of n_tracesink in 2011, but never fixed.

[1] GPF report
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<          (null)>]           (null)
    PGD 3752d067 PUD 37a7b067 PMD 0
    Oops: 0010 [#1] SMP KASAN
    Modules linked in:
    CPU: 2 PID: 148 Comm: kworker/u10:2 Not tainted 4.4.0-rc2+ #51
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Workqueue: events_unbound flush_to_ldisc
    task: ffff88006da94440 ti: ffff88006db60000 task.ti: ffff88006db60000
    RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
    RSP: 0018:ffff88006db67b50  EFLAGS: 00010246
    RAX: 0000000000000102 RBX: ffff88003ab32f88 RCX: 0000000000000102
    RDX: 0000000000000000 RSI: ffff88003ab330a6 RDI: ffff88003aabd388
    RBP: ffff88006db67c48 R08: ffff88003ab32f9c R09: ffff88003ab31fb0
    R10: ffff88003ab32fa8 R11: 0000000000000000 R12: dffffc0000000000
    R13: ffff88006db67c20 R14: ffffffff863df820 R15: ffff88003ab31fb8
    FS:  0000000000000000(0000) GS:ffff88006dc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000000 CR3: 0000000037938000 CR4: 00000000000006e0
    Stack:
     ffffffff829f46f1 ffff88006da94bf8 ffff88006da94bf8 0000000000000000
     ffff88003ab31fb0 ffff88003aabd438 ffff88003ab31ff8 ffff88006430fd90
     ffff88003ab32f9c ffffed0007557a87 1ffff1000db6cf78 ffff88003ab32078
    Call Trace:
     [] process_one_work+0x8f1/0x17a0 kernel/workqueue.c:2030
     [] worker_thread+0xd4/0x1180 kernel/workqueue.c:2162
     [] kthread+0x1cf/0x270 drivers/block/aoe/aoecmd.c:1302
     [] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:468
    Code:  Bad RIP value.
    RIP  [<          (null)>]           (null)
     RSP 
    CR2: 0000000000000000
    ---[ end trace a587f8947e54d6ea ]---

Reported-by: Dmitry Vyukov 
Cc: 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: Use unbound workqueue for all input workers

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

The commonly accepted wisdom that scheduling work on the same cpu
that handled interrupt i/o benefits from cache-locality is only
true if the cpu is idle (since bound kworkers are often the highest
vruntime and thus the lowest priority).

Measurements of scheduling via the unbound queue show lowered
worst-case latency responses of up to 5x over bound workqueue, without
increase in average latency or throughput.

pty i/o test measurements show >3x (!) reduced total running time; tests
previously taking ~8s now complete in <2.5s.

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

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: fix data race on tty_buffer.commit

2015-10-04T18:03:40+00:00

Race on buffer data happens when newly committed data is
picked up by an old flush work in the following scenario:
__tty_buffer_request_room does a plain write of tail->commit,
no barriers were executed before that.
At this point flush_to_ldisc reads this new value of commit,
and reads buffer data, no barriers in between.
The committed buffer data is not necessary visible to flush_to_ldisc.

Similar bug happens when tty_schedule_flip commits data.

Update commit with smp_store_release and read commit with
smp_load_acquire, as it is commit that signals data readiness.
This is orthogonal to the existing synchronization on tty_buffer.next,
which is required to not dismiss a buffer with unconsumed data.

The data race was found with KernelThreadSanitizer (KTSAN).

Signed-off-by: Dmitry Vyukov 
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: fix data race in tty_buffer_flush

2015-10-04T18:03:40+00:00

tty_buffer_flush frees not acquired buffers.
As the result, for example, read of b->size in tty_buffer_free
can return garbage value which will lead to a huge buffer
hanging in the freelist. This is just the benignest
manifestation of freeing of a not acquired object.
If the object is passed to kfree, heap can be corrupted.

Acquire visibility over the buffer before freeing it.

The data race was found with KernelThreadSanitizer (KTSAN).

Signed-off-by: Dmitry Vyukov 
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: fix data race in flush_to_ldisc

2015-10-04T18:03:40+00:00

flush_to_ldisc reads port->itty and checks that it is not NULL,
concurrently release_tty sets port->itty to NULL. It is possible
that flush_to_ldisc loads port->itty once, ensures that it is
not NULL, but then reloads it again and uses. The second load
can already return NULL, which will cause a crash.

Use READ_ONCE to read port->itty.

The data race was found with KernelThreadSanitizer (KTSAN).

Signed-off-by: Dmitry Vyukov 
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman