Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 09 12月, 2013 10 次提交
  3. 26 11月, 2013 10 次提交
    • G
      Revert "n_gsm: race between ld close and gsmtty open" · c42b4e65
      由 Greg Kroah-Hartman 提交于 
      This reverts commit c284ee2c.  Turns out
the locking was incorrect.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Cc: Chao Bi <chao.bi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c42b4e65
    • P
      n_tty: Protect minimum_to_wake reset for concurrent readers · aebf0453
      由 Peter Hurley 提交于 
      With multiple, concurrent readers (each waiting to acquire the
atomic_read_lock mutex), a departing reader may mistakenly reset
minimum_to_wake after a new reader has already set a new value.

Protect the minimum_to_wake reset with the atomic_read_lock critical
section.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aebf0453
    • P
      tty: Reset hupped state on open · d4855e1f
      由 Peter Hurley 提交于 
      A common security idiom is to hangup the current tty (via vhangup())
after forking but before execing a root shell. This hangs up any
existing opens which other processes may have and ensures subsequent
opens have the necessary permissions to open the root shell tty/pty.

Reset the TTY_HUPPED state after the driver has successfully
returned the opened tty (perform the reset while the tty is locked
to avoid racing with concurrent hangups).
Reported-by: NHeorhi Valakhanovich <valahanovich@tut.by>
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Cc: stable <stable@vger.kernel.org> # 3.12
Tested-by: NHeorhi Valakhanovich <valahanovich@tut.by>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d4855e1f
    • G
      TTY: amiserial, add missing platform check · 3dcf344b
      由 Geert Uytterhoeven 提交于 
      When booting a multi-platform m68k kernel on a non-Amiga with
"console=ttyS0" on the kernel command line, it crashes with:

Unable to handle kernel access at virtual address 81dff01c
Oops: 00000000
PC: [<001e09a8>] serial_console_write+0xc/0x70

Add the missing platform check to amiserial_console_init() to fix this.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3dcf344b
    • G
      TTY: pmac_zilog, check existence of ports in pmz_console_init() · dc1dc2f8
      由 Geert Uytterhoeven 提交于 
      When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0"
on the kernel command line, it crashes with:

Unable to handle kernel NULL pointer dereference at virtual address   (null)
Oops: 00000000
PC: [<0013ad28>] __pmz_startup+0x32/0x2a0
...
Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4

The normal tty driver doesn't crash, because init_pmz() checks
pmz_ports_count again after calling pmz_probe().

In the serial console initialization path, pmz_console_init() doesn't do
this, causing the driver to crash later.

Add a check for pmz_ports_count to fix this.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Finn Thain <fthain@telegraphics.com.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc1dc2f8
    • C
      n_gsm: race between ld close and gsmtty open · c284ee2c
      由 Chao Bi 提交于 
      ttyA has ld associated to n_gsm, when ttyA is closing, it triggers
to release gsmttyB's ld data dlci[B], then race would happen if gsmttyB
is opening in parallel.

Here are race cases we found recently in test:

CASE #1
====================================================================
releasing dlci[B] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(gsmttyB), as below:

 tty_release(ttyA)                  tty_open(gsmttyB)
     |                                   |
   -----                           gsmtty_install(gsmttyB)
     |                                   |
   -----                    gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
 tty_ldisc_release(ttyA)               -----
     |                                   |
 gsm_dlci_release(dlci[B])             -----
     |                                   |
 gsm_dlci_free(dlci[B])                -----
     |                                   |
   -----                           gsmtty_open(gsmttyB)

 gsmtty_open()
 {
     struct gsm_dlci *dlci = tty->driver_data; => here it uses dlci[B]
     ...
 }

 In gsmtty_open(gsmttyA), it uses dlci[B] which was release, so hit a panic.
=====================================================================

CASE #2
=====================================================================
releasing dlci[0] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(), as below:

 tty_release(ttyA)                  tty_open(gsmttyB)
     |                                   |
   -----                           gsmtty_install(gsmttyB)
     |                                   |
   -----                    gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
     |                                   |
   -----                         gsmtty_open(gsmttyB) fail
     |                                   |
   -----                           tty_release(gsmttyB)
     |                                   |
   -----                           gsmtty_close(gsmttyB)
     |                                   |
   -----                        gsmtty_detach_dlci(dlci[B])
     |                                   |
   -----                             dlci_put(dlci[B])
     |                                   |
 tty_ldisc_release(ttyA)               -----
     |                                   |
 gsm_dlci_release(dlci[0])             -----
     |                                   |
 gsm_dlci_free(dlci[0])                -----
     |                                   |
   -----                             dlci_put(dlci[0])

 In gsmtty_detach_dlci(dlci[B]), it tries to use dlci[0] which was released,
 then hit panic.
=====================================================================

IMHO, n_gsm tty operations would refer released ldisc,  as long as
gsm_dlci_release() has chance to release ldisc data when some gsmtty operations
are not completed..

This patch is try to avoid it by:

1) in n_gsm driver, use a global gsm spin lock to avoid gsm_dlci_release() run in
parallel with gsmtty_install();

2) Increase dlci's ref count in gsmtty_install() instead of in gsmtty_open(), the
purpose is to prevent gsm_dlci_release() releasing dlci after gsmtty_install()
allocats dlci but before gsmtty_open increases dlci's ref count;

3) Decrease dlci's ref count in gsmtty_remove(), which is a tty framework api, and
this is the opposite process of step 2).
Signed-off-by: NChao Bi <chao.bi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c284ee2c
    • R
      tty/serial/8250: fix typo in help text · f3014127
      由 Randy Dunlap 提交于 
      Commit 9326b047 includes a typo
of "8350_core" instead of "8250_core", so correct it.

Fixes kernel bugzilla #60724:
  https://bugzilla.kernel.org/show_bug.cgi?id=60724Reported-by: NChristoph Biedl <bugzilla.kernel.bpeb@manchmal.in-ulm.de>
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f3014127
    • P
      n_tty: Fix 4096-byte canonical reads · c77569d2
      由 Peter Hurley 提交于 
      Although the maximum allowable canonical line is specified to
be 255 bytes (MAX_CANON), the practical limit has actually been
the size of the line discipline read buffer (N_TTY_BUF_SIZE == 4096).

Commit 32f13521,
n_tty: Line copy to user buffer in canonical mode, limited the
line copy to 4095 bytes. With a completely full line discipline
read buffer and a userspace buffer > 4095, _no_ data was copied,
and the read() syscall returned 0, indicating EOF.

Fix the interval arithmetic to compute the correct number of bytes
to copy to userspace in the range [1..4096].

Cc: <stable@vger.kernel.org> # 3.12.x
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c77569d2
    • P
      n_tty: Fix echo overrun tail computation · 6f222536
      由 Peter Hurley 提交于 
      Commit cbfd0340,
'n_tty: Process echoes in blocks', introduced an error when
consuming the echo buffer tail to prevent buffer overrun, where
the incorrect operation code byte is checked to determine how
far to advance the tail to the next echo byte.

Check the correct byte for the echo operation code byte.

Cc: <stable@vger.kernel.org> # 3.12.x : c476f658 tty: incorrect test of echo_buf() result for ECHO_OP_START
Cc: <stable@vger.kernel.org> # 3.12.x
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f222536
    • P
      n_tty: Ensure reader restarts worker for next reader · 42458f41
      由 Peter Hurley 提交于 
      A departing reader must restart a flush_to_ldisc() worker _before_
the next reader enters the read loop; this is to avoid the new reader
concluding no more i/o is available and prematurely exiting, when the
old reader simply hasn't re-started the worker yet.

Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42458f41
  5. 15 11月, 2013 1 次提交
  7. 01 11月, 2013 1 次提交
  9. 30 10月, 2013 10 次提交
  11. 28 10月, 2013 1 次提交
  13. 25 10月, 2013 1 次提交
  15. 24 10月, 2013 1 次提交
  17. 20 10月, 2013 5 次提交