linux.git/drivers/tty/n_tty.c, branch v5.12 Linux kernel source tree Merge tag 'tty-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty 2021-02-21T05:28:04+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-02-21T05:28:04+00:00 e4286926abbbaab9b047c8bc25cae78ec990928f Pull tty/serial driver updates from Greg KH: "Here is the big set of tty/serial driver changes for 5.12-rc1. Nothing huge, just lots of good cleanups and additions: - n_tty line discipline cleanups - vt core cleanups and reworks to make the code more "modern" - stm32 driver additions - tty led support added to the tty core and led layer - minor serial driver fixups and additions All of these have been in linux-next for a while with no reported issues" * tag 'tty-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (54 commits) serial: core: Remove BUG_ON(in_interrupt()) check vt_ioctl: Remove in_interrupt() check dt-bindings: serial: imx: Switch to my personal address vt: keyboard, use new API for keyboard_tasklet serial: stm32: improve platform_get_irq condition handling in init_port serial: ifx6x60: Remove driver for deprecated platform tty: fix up iterate_tty_read() EOVERFLOW handling tty: fix up hung_up_tty_read() conversion tty: fix up hung_up_tty_write() conversion tty: teach the n_tty ICANON case about the new "cookie continuations" too tty: teach n_tty line discipline about the new "cookie continuations" tty: clean up legacy leftovers from n_tty line discipline tty: implement read_iter tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer serial: remove sirf prima/atlas driver serial: mxs-auart: Remove <asm/cacheflush.h> serial: mxs-auart: Remove serial_mxs_probe_dt() serial: fsl_lpuart: Use of_device_get_match_data() dt-bindings: serial: renesas,hscif: Add r8a779a0 support tty: serial: Drop unused efm32 serial driver ... 
Pull tty/serial driver updates from Greg KH:
 "Here is the big set of tty/serial driver changes for 5.12-rc1.

  Nothing huge, just lots of good cleanups and additions:

   - n_tty line discipline cleanups

   - vt core cleanups and reworks to make the code more "modern"

   - stm32 driver additions

   - tty led support added to the tty core and led layer

   - minor serial driver fixups and additions

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'tty-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (54 commits)
  serial: core: Remove BUG_ON(in_interrupt()) check
  vt_ioctl: Remove in_interrupt() check
  dt-bindings: serial: imx: Switch to my personal address
  vt: keyboard, use new API for keyboard_tasklet
  serial: stm32: improve platform_get_irq condition handling in init_port
  serial: ifx6x60: Remove driver for deprecated platform
  tty: fix up iterate_tty_read() EOVERFLOW handling
  tty: fix up hung_up_tty_read() conversion
  tty: fix up hung_up_tty_write() conversion
  tty: teach the n_tty ICANON case about the new "cookie continuations" too
  tty: teach n_tty line discipline about the new "cookie continuations"
  tty: clean up legacy leftovers from n_tty line discipline
  tty: implement read_iter
  tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer
  serial: remove sirf prima/atlas driver
  serial: mxs-auart: Remove <asm/cacheflush.h>
  serial: mxs-auart: Remove serial_mxs_probe_dt()
  serial: fsl_lpuart: Use of_device_get_match_data()
  dt-bindings: serial: renesas,hscif: Add r8a779a0 support
  tty: serial: Drop unused efm32 serial driver
  ...
Commit 9bb48c82aced ("tty: implement write_iter") converted the tty 2021-01-25T20:08:07+00:00 Sami Tolvanen samitolvanen@google.com 2021-01-25T19:09:25+00:00 9f12e37cae44a96132fc3031535a0b165486941a layer to use write_iter. Fix the redirected_tty_write declaration also in n_tty and change the comparisons to use write_iter instead of write. [ Also moved the declaration of redirected_tty_write() to the proper location in a header file. The reason for the bug was the bogus extern declaration in n_tty.c silently not matching the changed definition in tty_io.c, and because it wasn't in a shared header file, there was no cross-checking of the declaration. Sami noticed because Clang's Control Flow Integrity checking ended up incidentally noticing the inconsistent declaration. - Linus ] Fixes: 9bb48c82aced ("tty: implement write_iter") Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
layer to use write_iter. Fix the redirected_tty_write declaration
also in n_tty and change the comparisons to use write_iter instead of
write.

[ Also moved the declaration of redirected_tty_write() to the proper
  location in a header file. The reason for the bug was the bogus extern
  declaration in n_tty.c silently not matching the changed definition in
  tty_io.c, and because it wasn't in a shared header file, there was no
  cross-checking of the declaration.

  Sami noticed because Clang's Control Flow Integrity checking ended up
  incidentally noticing the inconsistent declaration.    - Linus ]

Fixes: 9bb48c82aced ("tty: implement write_iter")
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge branch 'tty-splice' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into tty-next 2021-01-21T08:40:55+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2021-01-21T08:40:55+00:00 3cfade53c77315d018c50ea1ee3420cef1c50fe7 Fixes both the "splice/sendfile to a tty" and "splice/sendfile from a tty" regression from 5.10. * 'tty-splice' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux: tty: teach the n_tty ICANON case about the new "cookie continuations" too tty: teach n_tty line discipline about the new "cookie continuations" tty: clean up legacy leftovers from n_tty line discipline tty: implement read_iter tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer tty: implement write_iter 
Fixes both the "splice/sendfile to a tty" and "splice/sendfile from a
tty" regression from 5.10.

* 'tty-splice' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux:
  tty: teach the n_tty ICANON case about the new "cookie continuations" too
  tty: teach n_tty line discipline about the new "cookie continuations"
  tty: clean up legacy leftovers from n_tty line discipline
  tty: implement read_iter
  tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer
  tty: implement write_iter
tty: teach the n_tty ICANON case about the new "cookie continuations" too 2021-01-21T00:48:49+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-01-20T23:43:38+00:00 d7fe75cbc23c7d225eee2ef04def239b6603dce7 The ICANON case is a bit messy, since it has to look for the line ending, and has special code to then suppress line ending characters if they match the __DISABLED_CHAR. So it actually looks up the line ending even past the point where it knows it won't copy it to the result buffer. That said, apart from all those odd legacy N_TTY ICANON cases, the actual "should we continue copying" logic isn't really all that complicated or different from the non-canon case. In fact, the lack of "wait for at least N characters" arguably makes the repeat case slightly simpler. It really just boils down to "there's more of the line to be copied". So add the necessarily trivial logic, and now the N_TTY case will give long result lines even when in canon mode. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
The ICANON case is a bit messy, since it has to look for the line
ending, and has special code to then suppress line ending characters if
they match the __DISABLED_CHAR.  So it actually looks up the line ending
even past the point where it knows it won't copy it to the result
buffer.

That said, apart from all those odd legacy N_TTY ICANON cases, the
actual "should we continue copying" logic isn't really all that
complicated or different from the non-canon case.  In fact, the lack of
"wait for at least N characters" arguably makes the repeat case slightly
simpler.  It really just boils down to "there's more of the line to be
copied".

So add the necessarily trivial logic, and now the N_TTY case will give
long result lines even when in canon mode.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
tty: teach n_tty line discipline about the new "cookie continuations" 2021-01-21T00:48:48+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-01-20T02:14:20+00:00 15ea8ae8e03fdb845ed3ff5d9f11dd5f4f60252c With the conversion to do the tty ldisc read operations in small chunks, the n_tty line discipline became noticeably slower for throughput oriented loads, because rather than read things in up to 2kB chunks, it would return at most 64 bytes per read() system call. The cost is mainly all in the "do system calls over and over", not really in the new "copy to an extra kernel buffer". This can be fixed by teaching the n_tty line discipline about the "cookie continuation" model, which the chunking code supports because things like hdlc need to be able to handle packets up to 64kB in size. Doing that doesn't just get us back to the old performace, but to much better performance: my stupid "copy 10MB of data over a pty" test program is now almost twice as fast as it used to be (going down from 0.1s to 0.054s). This is entirely because it now creates maximal chunks (which happens to be "one byte less than one page" due to how we do the circular tty buffers). NOTE! This case only handles the simpler non-icanon case, which is the one where people may care about throughput. I'm going to do the icanon case later too, because while performance isn't a major issue for that, there may be programs that think they'll always get a full line and don't like the 64-byte chunking for that reason. Such programs are arguably buggy (signals etc can cause random partial results from tty reads anyway), and good programs will handle such partial reads, but expecting everybody to write "good programs" has never been a winning policy for the kernel.. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
With the conversion to do the tty ldisc read operations in small chunks,
the n_tty line discipline became noticeably slower for throughput
oriented loads, because rather than read things in up to 2kB chunks, it
would return at most 64 bytes per read() system call.

The cost is mainly all in the "do system calls over and over", not
really in the new "copy to an extra kernel buffer".

This can be fixed by teaching the n_tty line discipline about the
"cookie continuation" model, which the chunking code supports because
things like hdlc need to be able to handle packets up to 64kB in size.

Doing that doesn't just get us back to the old performace, but to much
better performance: my stupid "copy 10MB of data over a pty" test
program is now almost twice as fast as it used to be (going down from
0.1s to 0.054s).

This is entirely because it now creates maximal chunks (which happens to
be "one byte less than one page" due to how we do the circular tty
buffers).

NOTE! This case only handles the simpler non-icanon case, which is the
one where people may care about throughput.  I'm going to do the icanon
case later too, because while performance isn't a major issue for that,
there may be programs that think they'll always get a full line and
don't like the 64-byte chunking for that reason.

Such programs are arguably buggy (signals etc can cause random partial
results from tty reads anyway), and good programs will handle such
partial reads, but expecting everybody to write "good programs" has
never been a winning policy for the kernel..

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
tty: clean up legacy leftovers from n_tty line discipline 2021-01-21T00:48:48+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-01-19T21:46:28+00:00 64a69892afadd6fffaeadc65427bb7601161139d Back when the line disciplines did their own direct user accesses, they had to deal with the data copy possibly failing in the middle. Now that the user copy is done by the tty_io.c code, that failure case no longer exists. Remove the left-over error handling code that cannot trigger. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Back when the line disciplines did their own direct user accesses, they
had to deal with the data copy possibly failing in the middle.

Now that the user copy is done by the tty_io.c code, that failure case
no longer exists.

Remove the left-over error handling code that cannot trigger.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer 2021-01-21T00:48:47+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-01-18T21:31:30+00:00 3b830a9c34d5897be07176ce4e6f2d75e2c8cfd7 The tty line discipline .read() function was passed the final user pointer destination as an argument, which doesn't match the 'write()' function, and makes it very inconvenient to do a splice method for ttys. This is a conversion to use a kernel buffer instead. NOTE! It does this by passing the tty line discipline ->read() function an additional "cookie" to fill in, and an offset into the cookie data. The line discipline can fill in the cookie data with its own private information, and then the reader will repeat the read until either the cookie is cleared or it runs out of data. The only real user of this is N_HDLC, which can use this to handle big packets, even if the kernel buffer is smaller than the whole packet. Cc: Christoph Hellwig <hch@lst.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
The tty line discipline .read() function was passed the final user
pointer destination as an argument, which doesn't match the 'write()'
function, and makes it very inconvenient to do a splice method for
ttys.

This is a conversion to use a kernel buffer instead.

NOTE! It does this by passing the tty line discipline ->read() function
an additional "cookie" to fill in, and an offset into the cookie data.

The line discipline can fill in the cookie data with its own private
information, and then the reader will repeat the read until either the
cookie is cleared or it runs out of data.

The only real user of this is N_HDLC, which can use this to handle big
packets, even if the kernel buffer is smaller than the whole packet.

Cc: Christoph Hellwig <hch@lst.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
tty: Protect disc_data in n_tty_close and n_tty_flush_buffer 2021-01-07T15:34:26+00:00 Yan.Gao gao.yanB@h3c.com 2020-12-10T02:25:07+00:00 c9cd57bf57fd450972a7802b9f09a680dbb4634e n_tty_flush_buffer can happen in parallel with n_tty_close that the tty->disc_data will be set to NULL. n_tty_flush_buffer accesses tty->disc_data, so we must prevent n_tty_close clear tty->disc_data while n_tty_flush_buffer has a non-NULL view of tty->disc_data. So we need to make sure that accesses to disc_data are atomic using tty->termios_rwsem. There is an example I meet: When n_tty_flush_buffer accesses tty struct, the disc_data is right. However, then reset_buffer_flags accesses tty->disc_data, disc_data become NULL, So kernel crash when accesses tty->disc_data->real_tail. I guess there could be another thread change tty->disc_data to NULL, and during N_TTY line discipline, n_tty_close will set tty->disc_data to be NULL. So use tty->termios_rwsem to protect disc_data between close and flush_buffer. IP: reset_buffer_flags+0x9/0xf0 PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 23 PID: 2087626 Comm: (agetty) Kdump: loaded Tainted: G Hardware name: UNISINSIGHT X3036P-G3/ST01M2C7S, BIOS 2.00.13 01/11/2019 task: ffff9c4e9da71e80 task.stack: ffffb30cfe898000 RIP: 0010:reset_buffer_flags+0x9/0xf0 RSP: 0018:ffffb30cfe89bca8 EFLAGS: 00010246 RAX: ffff9c4e9da71e80 RBX: ffff9c368d1bac00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9c4ea17b50f0 RDI: 0000000000000000 RBP: ffffb30cfe89bcc8 R08: 0000000000000100 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: ffff9c368d1bacc0 R13: ffff9c20cfd18428 R14: ffff9c4ea17b50f0 R15: ffff9c368d1bac00 FS: 00007f9fbbe97940(0000) GS:ffff9c375c740000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000002260 CR3: 0000002f72233003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? n_tty_flush_buffer+0x2a/0x60 tty_buffer_flush+0x76/0x90 tty_ldisc_flush+0x22/0x40 vt_ioctl+0x5a7/0x10b0 ? n_tty_ioctl_helper+0x27/0x110 tty_ioctl+0xef/0x8c0 do_vfs_ioctl+0xa7/0x5e0 ? __audit_syscall_entry+0xaf/0x100 ? syscall_trace_enter+0x1d0/0x2b0 SyS_ioctl+0x79/0x90 do_syscall_64+0x6c/0x1b0 entry_SYSCALL64_slow_path+0x25/0x25 n_tty_flush_buffer --->tty->disc_data is OK ->reset_buffer_flags -->tty->disc_data is NULL Signed-off-by: Yan.Gao <gao.yanB@h3c.com> Reviewed-by: Xianting Tian <tian.xianting@h3c.com> Link: https://lore.kernel.org/r/20201210022507.30729-1-gao.yanB@h3c.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
n_tty_flush_buffer can happen in parallel with n_tty_close that the
tty->disc_data will be set to NULL. n_tty_flush_buffer accesses
tty->disc_data, so we must prevent n_tty_close clear tty->disc_data
while n_tty_flush_buffer  has a non-NULL view of tty->disc_data.

So we need to make sure that accesses to disc_data are atomic using
tty->termios_rwsem.

There is an example I meet:
When n_tty_flush_buffer accesses tty struct, the disc_data is right.
However, then reset_buffer_flags accesses tty->disc_data, disc_data
become NULL, So kernel crash when accesses tty->disc_data->real_tail.
I guess there could be another thread change tty->disc_data to NULL,
and during N_TTY line discipline, n_tty_close will set tty->disc_data
to be NULL. So use tty->termios_rwsem to protect disc_data between close
and flush_buffer.

IP: reset_buffer_flags+0x9/0xf0
PGD 0 P4D 0
Oops: 0002 [#1] SMP
CPU: 23 PID: 2087626 Comm: (agetty) Kdump: loaded Tainted: G
Hardware name: UNISINSIGHT X3036P-G3/ST01M2C7S, BIOS 2.00.13 01/11/2019
task: ffff9c4e9da71e80 task.stack: ffffb30cfe898000
RIP: 0010:reset_buffer_flags+0x9/0xf0
RSP: 0018:ffffb30cfe89bca8 EFLAGS: 00010246
RAX: ffff9c4e9da71e80 RBX: ffff9c368d1bac00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9c4ea17b50f0 RDI: 0000000000000000
RBP: ffffb30cfe89bcc8 R08: 0000000000000100 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffff9c368d1bacc0
R13: ffff9c20cfd18428 R14: ffff9c4ea17b50f0 R15: ffff9c368d1bac00
FS:  00007f9fbbe97940(0000) GS:ffff9c375c740000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000002260 CR3: 0000002f72233003 CR4: 00000000007606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
? n_tty_flush_buffer+0x2a/0x60
tty_buffer_flush+0x76/0x90
tty_ldisc_flush+0x22/0x40
vt_ioctl+0x5a7/0x10b0
? n_tty_ioctl_helper+0x27/0x110
tty_ioctl+0xef/0x8c0
do_vfs_ioctl+0xa7/0x5e0
? __audit_syscall_entry+0xaf/0x100
? syscall_trace_enter+0x1d0/0x2b0
SyS_ioctl+0x79/0x90
do_syscall_64+0x6c/0x1b0
entry_SYSCALL64_slow_path+0x25/0x25

n_tty_flush_buffer			--->tty->disc_data is OK
	->reset_buffer_flags		 -->tty->disc_data is NULL

Signed-off-by: Yan.Gao <gao.yanB@h3c.com>
Reviewed-by: Xianting Tian <tian.xianting@h3c.com>
Link: https://lore.kernel.org/r/20201210022507.30729-1-gao.yanB@h3c.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty: n_tty: Add 2 missing parameter descriptions 2020-11-06T09:49:27+00:00 Lee Jones lee.jones@linaro.org 2020-11-04T19:35:23+00:00 171044a70b5750ea621659b143c075a47c1bfe40 Fixes the following W=1 kernel build warning(s): drivers/tty/n_tty.c:405: warning: Function parameter or member 'tty' not described in 'is_continuation' drivers/tty/n_tty.c:1701: warning: Function parameter or member 'flow' not described in 'n_tty_receive_buf_common' Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: "Andrew J. Kroll" <ag784@freenet.buffalo.edu> Cc: processes-Sapan Bhatia <sapan@corewars.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20201104193549.4026187-11-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Fixes the following W=1 kernel build warning(s):

 drivers/tty/n_tty.c:405: warning: Function parameter or member 'tty' not described in 'is_continuation'
 drivers/tty/n_tty.c:1701: warning: Function parameter or member 'flow' not described in 'n_tty_receive_buf_common'

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: "Andrew J. Kroll" <ag784@freenet.buffalo.edu>
Cc: processes-Sapan Bhatia <sapan@corewars.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20201104193549.4026187-11-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty: ldiscs, fix kernel-doc 2020-08-18T11:51:18+00:00 Jiri Slaby jslaby@suse.cz 2020-08-18T08:56:52+00:00 724ac070ffc7a1e7526be4408edbd324a4163e15 As in the previous patch, fix kernel-doc in line disciplines. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200818085655.12071-5-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
As in the previous patch, fix kernel-doc in line disciplines.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200818085655.12071-5-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>