[SRU X] [PATCH 0/5] Line discipline buffer flush/tty_reopen() race fix

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[SRU X] [PATCH 0/5] Line discipline buffer flush/tty_reopen() race fix

Guilherme Piccoli
BugLink: https://bugs.launchpad.net/bugs/1791758

[Impact]

* Line discipline code is racy when we have buffer being flush while the
tty is being initialized or reinitialized. For the first problem, we have
an upstream patch since January 2018:
b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf");
although it is not in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent
ones.

* For the race between the buffer flush while tty is being reopened, we
have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()").
No Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].

* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are necessary to prevent
correlated issues, like preventing a potential deadlock due to bad
prioritization in servicing I/O over releasing tty_ldisc_lock() - refer to
c96cf923a98d ("tty: Don't block on IO when ldisc change is pending").
All the necessary fixes are grouped here in this SRU request.

* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:


BUG: unable to handle kernel paging request at 0000000000002268
IP: [<addr>] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[<addr>] ? kvm_sched_clock_read+0x1e/0x30
[<addr>] n_tty_receive_buf2+0x14/0x20
[<addr>] flush_to_ldisc+0xd5/0x120
[<addr>] process_one_work+0x156/0x400
[<addr>] worker_thread+0x11a/0x480
[...]


* A kernel crash was collected from an user, analysis is present in
comment #4 in LP #1791758.


[Test Case]

* It is not trivial to trigger this fault, but the usual recipe is to keep
accessing a machine through SSH (or keep killing getty when in IPMI serial
console) and in some way run commands before the terminal is ready in that
machine (like hacking some echo into ttySx or pts in an infinite loop).

* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU request
the problem was fixed.


[Regression Potential]

* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due to
a hard to reproduce issue reported in the PA-RISC architecture, which was
found in the V5 iteration [1] but was fixed by the patch c96cf923a98d,
present in this SRU request.

* The patchset [0] is present in tty-next tree since mid-November, and the
patch b027e2298bd5 is available upstream since January/2018 (it's available
in both Ubuntu kernels 4.15 and 4.18), so the overall likelihood of
regressions is low.

* These patches were sniff-tested for the 3 versions (4.4, 4.15 and 4.18)
and didn't show any issues.


[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183


Dmitry Safonov (4):
  tty: Drop tty->count on tty_reopen() failure
  tty: Hold tty_ldisc_lock() during tty_reopen()
  tty: Don't block on IO when ldisc change is pending
  tty: Simplify tty->count math in tty_reopen()

Gaurav Kohli (1):
  tty: fix data race between tty_init_dev and flush of buf

 drivers/tty/n_hdlc.c    |  4 ++--
 drivers/tty/n_r3964.c   |  2 +-
 drivers/tty/n_tty.c     |  8 ++++----
 drivers/tty/tty_io.c    | 20 +++++++++++++++++---
 drivers/tty/tty_ldisc.c | 11 +++++++++--
 include/linux/tty.h     |  9 +++++++++
 6 files changed, 42 insertions(+), 12 deletions(-)

--
2.19.2


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU X] [PATCH 1/5] tty: fix data race between tty_init_dev and flush of buf

Guilherme Piccoli
From: Gaurav Kohli <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1791758

There can be a race, if receive_buf call comes before
tty initialization completes in n_tty_open and tty->disc_data
may be NULL.

CPU0 CPU1
---- ----
 000|n_tty_receive_buf_common()   n_tty_open()
-001|n_tty_receive_buf2() tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline) tty_ldisc_setup()

Using ldisc semaphore lock in tty_init_dev till disc_data
initializes completely.

Signed-off-by: Gaurav Kohli <[hidden email]>
Reviewed-by: Alan Cox <[hidden email]>
Cc: stable <[hidden email]>

Signed-off-by: Greg Kroah-Hartman <[hidden email]>
(backported from b027e2298bd588d6fa36ed2eda97447fb3eac078 upstream)
[gpiccoli: context adjustment, kept the __lockfunc mark in tty_ldisc_lock()]
Signed-off-by: Guilherme G. Piccoli <[hidden email]>
---
 drivers/tty/tty_io.c    | 7 +++++++
 drivers/tty/tty_ldisc.c | 4 ++--
 include/linux/tty.h     | 2 ++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 3f44d28ae2da..2ed3d2add7d4 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1551,6 +1551,9 @@ struct tty_struct *tty_init_dev(struct tty_driver *driver, int idx)
  "%s: %s driver does not set tty->port. This will crash the kernel later. Fix the driver!\n",
  __func__, tty->driver->name);
 
+ retval = tty_ldisc_lock(tty, 5 * HZ);
+ if (retval)
+ goto err_release_lock;
  tty->port->itty = tty;
 
  /*
@@ -1561,6 +1564,7 @@ struct tty_struct *tty_init_dev(struct tty_driver *driver, int idx)
  retval = tty_ldisc_setup(tty, tty->link);
  if (retval)
  goto err_release_tty;
+ tty_ldisc_unlock(tty);
  /* Return the tty locked so that it cannot vanish under the caller */
  return tty;
 
@@ -1575,8 +1579,11 @@ err_module_put:
  /* call the tty release_tty routine to clean out this slot */
 err_release_tty:
  tty_unlock(tty);
+ tty_ldisc_unlock(tty);
  printk_ratelimited(KERN_INFO "tty_init_dev: ldisc open failed, "
  "clearing slot %d\n", idx);
+err_release_lock:
+ tty_unlock(tty);
  release_tty(tty, idx);
  return ERR_PTR(retval);
 }
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 7e3b725af8fa..fdc2c830a45c 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -325,7 +325,7 @@ static inline void __tty_ldisc_unlock(struct tty_struct *tty)
  ldsem_up_write(&tty->ldisc_sem);
 }
 
-static int __lockfunc
+int __lockfunc
 tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout)
 {
  int ret;
@@ -337,7 +337,7 @@ tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout)
  return 0;
 }
 
-static void tty_ldisc_unlock(struct tty_struct *tty)
+void tty_ldisc_unlock(struct tty_struct *tty)
 {
  clear_bit(TTY_LDISC_HALTED, &tty->flags);
  __tty_ldisc_unlock(tty);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index f2bfe07c983a..8927d8270620 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -374,6 +374,8 @@ extern struct tty_struct *get_current_tty(void);
 /* tty_io.c */
 extern int __init tty_init(void);
 extern const char *tty_name(const struct tty_struct *tty);
+extern int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout);
+extern void tty_ldisc_unlock(struct tty_struct *tty);
 #else
 static inline void console_init(void)
 { }
--
2.19.2


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU X] [PATCH 2/5] tty: Drop tty->count on tty_reopen() failure

Guilherme Piccoli
In reply to this post by Guilherme Piccoli
From: Dmitry Safonov <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1791758

In case of tty_ldisc_reinit() failure, tty->count should be decremented
back, otherwise we will never release_tty().
Tetsuo reported that it fixes noisy warnings on tty release like:
  pts pts4033: tty_release: tty->count(10529) != (#fd's(7) + #kopen's(0))

Fixes: commit 892d1fa7eaae ("tty: Destroy ldisc instance on hangup")

Cc: [hidden email] # v4.6+
Cc: Greg Kroah-Hartman <[hidden email]>
Cc: Jiri Slaby <[hidden email]>
Reviewed-by: Jiri Slaby <[hidden email]>
Tested-by: Jiri Slaby <[hidden email]>
Tested-by: Mark Rutland <[hidden email]>
Tested-by: Tetsuo Handa <[hidden email]>
Signed-off-by: Dmitry Safonov <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>
(cherry-picked from fe32416790093b31364c08395727de17ec96ace1 upstream)
Signed-off-by: Guilherme G. Piccoli <[hidden email]>
---
 drivers/tty/tty_io.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 2ed3d2add7d4..d2f00378fc18 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1474,6 +1474,7 @@ void tty_driver_remove_tty(struct tty_driver *driver, struct tty_struct *tty)
 static int tty_reopen(struct tty_struct *tty)
 {
  struct tty_driver *driver = tty->driver;
+ int retval;
 
  if (driver->type == TTY_DRIVER_TYPE_PTY &&
     driver->subtype == PTY_TYPE_MASTER)
@@ -1487,10 +1488,14 @@ static int tty_reopen(struct tty_struct *tty)
 
  tty->count++;
 
- if (!tty->ldisc)
- return tty_ldisc_reinit(tty, tty->termios.c_line);
+ if (tty->ldisc)
+ return 0;
 
- return 0;
+ retval = tty_ldisc_reinit(tty, tty->termios.c_line);
+ if (retval)
+ tty->count--;
+
+ return retval;
 }
 
 /**
--
2.19.2


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU X] [PATCH 3/5] tty: Hold tty_ldisc_lock() during tty_reopen()

Guilherme Piccoli
In reply to this post by Guilherme Piccoli
From: Dmitry Safonov <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1791758

tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup()
nor set_ldisc() nor tty_ldisc_release() as they use tty lock.
But it races with anyone who expects line discipline to be the same
after hoding read semaphore in tty_ldisc_ref().

We've seen the following crash on v4.9.108 stable:

BUG: unable to handle kernel paging request at 0000000000002260
IP: [..] n_tty_receive_buf_common+0x5f/0x86d
Workqueue: events_unbound flush_to_ldisc
Call Trace:
 [..] n_tty_receive_buf2
 [..] tty_ldisc_receive_buf
 [..] flush_to_ldisc
 [..] process_one_work
 [..] worker_thread
 [..] kthread
 [..] ret_from_fork

tty_ldisc_reinit() should be called with ldisc_sem hold for writing,
which will protect any reader against line discipline changes.

Cc: Jiri Slaby <[hidden email]>
Cc: [hidden email] # b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf")
Reviewed-by: Jiri Slaby <[hidden email]>
Reported-by: [hidden email]
Tested-by: Mark Rutland <[hidden email]>
Tested-by: Tetsuo Handa <[hidden email]>
Signed-off-by: Dmitry Safonov <[hidden email]>
Tested-by: Tycho Andersen <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>
(cherry-picked from 83d817f41070c48bc3eb7ec18e43000a548fca5c upstream)
Signed-off-by: Guilherme G. Piccoli <[hidden email]>
---
 drivers/tty/tty_io.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index d2f00378fc18..3784f55f3dc9 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1486,15 +1486,20 @@ static int tty_reopen(struct tty_struct *tty)
  if (test_bit(TTY_EXCLUSIVE, &tty->flags) && !capable(CAP_SYS_ADMIN))
  return -EBUSY;
 
- tty->count++;
+ retval = tty_ldisc_lock(tty, 5 * HZ);
+ if (retval)
+ return retval;
 
+ tty->count++;
  if (tty->ldisc)
- return 0;
+ goto out_unlock;
 
  retval = tty_ldisc_reinit(tty, tty->termios.c_line);
  if (retval)
  tty->count--;
 
+out_unlock:
+ tty_ldisc_unlock(tty);
  return retval;
 }
 
--
2.19.2


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU X] [PATCH 4/5] tty: Don't block on IO when ldisc change is pending

Guilherme Piccoli
In reply to this post by Guilherme Piccoli
From: Dmitry Safonov <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1791758

There might be situations where tty_ldisc_lock() has blocked, but there
is already IO on tty and it prevents line discipline changes.
It might theoretically turn into dead-lock.

Basically, provide more priority to pending tty_ldisc_lock() than to
servicing reads/writes over tty.

User-visible issue was reported by Mikulas where on pa-risc with
Debian 5 reboot took either 80 seconds, 3 minutes or 3:25 after proper
locking in tty_reopen().

Cc: Jiri Slaby <[hidden email]>
Reported-by: Mikulas Patocka <[hidden email]>
Signed-off-by: Dmitry Safonov <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>
(backported from c96cf923a98d1b094df9f0cf97a83e118817e31b upstream)
[gpiccoli: context adjustment]
Signed-off-by: Guilherme G. Piccoli <[hidden email]>
---
 drivers/tty/n_hdlc.c    | 4 ++--
 drivers/tty/n_r3964.c   | 2 +-
 drivers/tty/n_tty.c     | 8 ++++----
 drivers/tty/tty_ldisc.c | 7 +++++++
 include/linux/tty.h     | 7 +++++++
 5 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/n_hdlc.c b/drivers/tty/n_hdlc.c
index 6d1e2f746ab4..401a650d7df1 100644
--- a/drivers/tty/n_hdlc.c
+++ b/drivers/tty/n_hdlc.c
@@ -613,7 +613,7 @@ static ssize_t n_hdlc_tty_read(struct tty_struct *tty, struct file *file,
  }
 
  /* no data */
- if (file->f_flags & O_NONBLOCK) {
+ if (tty_io_nonblock(tty, file)) {
  ret = -EAGAIN;
  break;
  }
@@ -680,7 +680,7 @@ static ssize_t n_hdlc_tty_write(struct tty_struct *tty, struct file *file,
  if (tbuf)
  break;
 
- if (file->f_flags & O_NONBLOCK) {
+ if (tty_io_nonblock(tty, file)) {
  error = -EAGAIN;
  break;
  }
diff --git a/drivers/tty/n_r3964.c b/drivers/tty/n_r3964.c
index 345111467b85..ee0e07b4a13d 100644
--- a/drivers/tty/n_r3964.c
+++ b/drivers/tty/n_r3964.c
@@ -1080,7 +1080,7 @@ static ssize_t r3964_read(struct tty_struct *tty, struct file *file,
  pMsg = remove_msg(pInfo, pClient);
  if (pMsg == NULL) {
  /* no messages available. */
- if (file->f_flags & O_NONBLOCK) {
+ if (tty_io_nonblock(tty, file)) {
  ret = -EAGAIN;
  goto unlock;
  }
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index b1ec202099b2..940f6f171b89 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1722,7 +1722,7 @@ n_tty_receive_buf_common(struct tty_struct *tty, const unsigned char *cp,
 
  down_read(&tty->termios_rwsem);
 
- while (1) {
+ do {
  /*
  * When PARMRK is set, each input char may take up to 3 chars
  * in the read buf; reduce the buffer space avail by 3x
@@ -1764,7 +1764,7 @@ n_tty_receive_buf_common(struct tty_struct *tty, const unsigned char *cp,
  fp += n;
  count -= n;
  rcvd += n;
- }
+ } while (!test_bit(TTY_LDISC_CHANGING, &tty->flags));
 
  tty->receive_room = room;
 
@@ -2255,7 +2255,7 @@ static ssize_t n_tty_read(struct tty_struct *tty, struct file *file,
  break;
  if (!timeout)
  break;
- if (file->f_flags & O_NONBLOCK) {
+ if (tty_io_nonblock(tty, file)) {
  retval = -EAGAIN;
  break;
  }
@@ -2412,7 +2412,7 @@ static ssize_t n_tty_write(struct tty_struct *tty, struct file *file,
  }
  if (!nr)
  break;
- if (file->f_flags & O_NONBLOCK) {
+ if (tty_io_nonblock(tty, file)) {
  retval = -EAGAIN;
  break;
  }
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index fdc2c830a45c..bdae7db8ce76 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -330,6 +330,11 @@ tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout)
 {
  int ret;
 
+ /* Kindly asking blocked readers to release the read side */
+ set_bit(TTY_LDISC_CHANGING, &tty->flags);
+ wake_up_interruptible_all(&tty->read_wait);
+ wake_up_interruptible_all(&tty->write_wait);
+
  ret = __tty_ldisc_lock(tty, timeout);
  if (!ret)
  return -EBUSY;
@@ -340,6 +345,8 @@ tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout)
 void tty_ldisc_unlock(struct tty_struct *tty)
 {
  clear_bit(TTY_LDISC_HALTED, &tty->flags);
+ /* Can be cleared here - ldisc_unlock will wake up writers firstly */
+ clear_bit(TTY_LDISC_CHANGING, &tty->flags);
  __tty_ldisc_unlock(tty);
 }
 
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 8927d8270620..ac687ab3320e 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -343,6 +343,7 @@ struct tty_file_private {
 #define TTY_NO_WRITE_SPLIT 17 /* Preserve write boundaries to driver */
 #define TTY_HUPPED 18 /* Post driver->hangup() */
 #define TTY_HUPPING 19 /* Hangup in progress */
+#define TTY_LDISC_CHANGING 20 /* Change pending - non-block IO */
 #define TTY_LDISC_HALTED 22 /* Line discipline is halted */
 
 #define TTY_WRITE_FLUSH(tty) tty_write_flush((tty))
@@ -362,6 +363,12 @@ static inline void tty_set_flow_change(struct tty_struct *tty, int val)
  smp_mb();
 }
 
+static inline bool tty_io_nonblock(struct tty_struct *tty, struct file *file)
+{
+ return file->f_flags & O_NONBLOCK ||
+ test_bit(TTY_LDISC_CHANGING, &tty->flags);
+}
+
 #ifdef CONFIG_TTY
 extern void console_init(void);
 extern void tty_kref_put(struct tty_struct *tty);
--
2.19.2


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU X] [PATCH 5/5] tty: Simplify tty->count math in tty_reopen()

Guilherme Piccoli
In reply to this post by Guilherme Piccoli
From: Dmitry Safonov <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1791758

As notted by Jiri, tty_ldisc_reinit() shouldn't rely on tty counter.
Simplify math by increasing the counter after reinit success.

Cc: Jiri Slaby <[hidden email]>
Link: lkml.kernel.org/r/<[hidden email]>
Suggested-by: Jiri Slaby <[hidden email]>
Reviewed-by: Jiri Slaby <[hidden email]>
Tested-by: Mark Rutland <[hidden email]>
Signed-off-by: Dmitry Safonov <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>
(cherry-picked from cf62a1a13749db0d32b5cdd800ea91a4087319de upstream)
Signed-off-by: Guilherme G. Piccoli <[hidden email]>
---
 drivers/tty/tty_io.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 3784f55f3dc9..a7511d5fad9e 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1490,16 +1490,13 @@ static int tty_reopen(struct tty_struct *tty)
  if (retval)
  return retval;
 
- tty->count++;
- if (tty->ldisc)
- goto out_unlock;
-
- retval = tty_ldisc_reinit(tty, tty->termios.c_line);
- if (retval)
- tty->count--;
-
-out_unlock:
+ if (!tty->ldisc)
+ retval = tty_ldisc_reinit(tty, tty->termios.c_line);
  tty_ldisc_unlock(tty);
+
+ if (retval == 0)
+ tty->count++;
+
  return retval;
 }
 
--
2.19.2


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK/cmnt: [SRU X] [PATCH 0/5] Line discipline buffer flush/tty_reopen() race fix

Kleber Souza
In reply to this post by Guilherme Piccoli
On 1/8/19 9:18 PM, Guilherme G. Piccoli wrote:

> BugLink: https://bugs.launchpad.net/bugs/1791758
>
> [Impact]
>
> * Line discipline code is racy when we have buffer being flush while the
> tty is being initialized or reinitialized. For the first problem, we have
> an upstream patch since January 2018:
> b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf");
> although it is not in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent
> ones.
>
> * For the race between the buffer flush while tty is being reopened, we
> have a patch that addresses this issue recently merged for 5.0-rc1:
> 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()").
> No Ubuntu kernel currently contains this patch, hence we're hereby
> submitting the SRU request. The upstream complete patch series for
> this is in [0].
>
> * The approach of both patches are similar - they rely in locking/semaphore
> to prevent race conditions. Some additional patches are necessary to prevent
> correlated issues, like preventing a potential deadlock due to bad
> prioritization in servicing I/O over releasing tty_ldisc_lock() - refer to
> c96cf923a98d ("tty: Don't block on IO when ldisc change is pending").
> All the necessary fixes are grouped here in this SRU request.
>
> * The symptom of the race condition between the buffer flush and the
> tty reopen routine is a kernel crash with the following trace:
>
>
> BUG: unable to handle kernel paging request at 0000000000002268
> IP: [<addr>] n_tty_receive_buf_common+0x6a/0xae0
> [...]
> Call Trace:
> [<addr>] ? kvm_sched_clock_read+0x1e/0x30
> [<addr>] n_tty_receive_buf2+0x14/0x20
> [<addr>] flush_to_ldisc+0xd5/0x120
> [<addr>] process_one_work+0x156/0x400
> [<addr>] worker_thread+0x11a/0x480
> [...]
>
>
> * A kernel crash was collected from an user, analysis is present in
> comment #4 in LP #1791758.
>
>
> [Test Case]
>
> * It is not trivial to trigger this fault, but the usual recipe is to keep
> accessing a machine through SSH (or keep killing getty when in IPMI serial
> console) and in some way run commands before the terminal is ready in that
> machine (like hacking some echo into ttySx or pts in an infinite loop).
>
> * We have reports of users that could reproduce this issue in their
> production environment, and with the patches present in this SRU request
> the problem was fixed.
>
>
> [Regression Potential]
>
> * tty subsystem is highly central and patches in that area are always
> delicate. For example, the upstream series [0] is a re-spin (V6) due to
> a hard to reproduce issue reported in the PA-RISC architecture, which was
> found in the V5 iteration [1] but was fixed by the patch c96cf923a98d,
> present in this SRU request.
>
> * The patchset [0] is present in tty-next tree since mid-November, and the
> patch b027e2298bd5 is available upstream since January/2018 (it's available
> in both Ubuntu kernels 4.15 and 4.18), so the overall likelihood of
> regressions is low.
>
> * These patches were sniff-tested for the 3 versions (4.4, 4.15 and 4.18)
> and didn't show any issues.
>
>
> [0] https://marc.info/?l=linux-kernel&m=154103190111795
> [1] https://marc.info/?l=linux-kernel&m=153737852618183
>
>
> Dmitry Safonov (4):
>   tty: Drop tty->count on tty_reopen() failure
>   tty: Hold tty_ldisc_lock() during tty_reopen()
>   tty: Don't block on IO when ldisc change is pending
>   tty: Simplify tty->count math in tty_reopen()
>
> Gaurav Kohli (1):
>   tty: fix data race between tty_init_dev and flush of buf
>
>  drivers/tty/n_hdlc.c    |  4 ++--
>  drivers/tty/n_r3964.c   |  2 +-
>  drivers/tty/n_tty.c     |  8 ++++----
>  drivers/tty/tty_io.c    | 20 +++++++++++++++++---
>  drivers/tty/tty_ldisc.c | 11 +++++++++--
>  include/linux/tty.h     |  9 +++++++++
>  6 files changed, 42 insertions(+), 12 deletions(-)
>
Those are indeed some sensitive changes and a bit intrusive, but they
are needed to fix the issue and most of them have been around on
mainline for some time now. I guess we'll also detect issues with
regression tests if they can be easily broken.

Please note that the required format for the provenance of the patch is:

 (backported from commit <sha1> <upstream repo name>)
or
 (cherry-pick from commit <sha1> <upstream repo name>)

so the "commit" part is missing on those patches. The <upstream repo
name> can be omitted if they come from upstream. This can be fixed when
applying, but please keep it in mind for the next submissions :-).


Acked-by: Kleber Sacilotto de Souza <[hidden email]>



--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: ACK/cmnt: [SRU X] [PATCH 0/5] Line discipline buffer flush/tty_reopen() race fix

Guilherme Piccoli
On Wed, Jan 9, 2019 at 7:57 AM Kleber Souza <[hidden email]> wrote:

> [...]
> Those are indeed some sensitive changes and a bit intrusive, but they
> are needed to fix the issue and most of them have been around on
> mainline for some time now. I guess we'll also detect issues with
> regression tests if they can be easily broken.
>
> Please note that the required format for the provenance of the patch is:
>
>  (backported from commit <sha1> <upstream repo name>)
> or
>  (cherry-pick from commit <sha1> <upstream repo name>)
>
> so the "commit" part is missing on those patches. The <upstream repo
> name> can be omitted if they come from upstream. This can be fixed when
> applying, but please keep it in mind for the next submissions :-).
>
>
> Acked-by: Kleber Sacilotto de Souza <[hidden email]>
>
>

Thanks Kleber, for the ack! Sorry for the missing "commit" word, I'm not sure
how I forgot it heheh
Sent some SRUs last weeks, and for some reason, my mind forgot this here.

Cheers,


Guilherme

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: ACK/cmnt: [SRU X] [PATCH 0/5] Line discipline buffer flush/tty_reopen() race fix

Stefan Bader-2
In reply to this post by Kleber Souza
On 09.01.19 10:57, Kleber Souza wrote:

> On 1/8/19 9:18 PM, Guilherme G. Piccoli wrote:
>> BugLink: https://bugs.launchpad.net/bugs/1791758
>>
>> [Impact]
>>
>> * Line discipline code is racy when we have buffer being flush while the
>> tty is being initialized or reinitialized. For the first problem, we have
>> an upstream patch since January 2018:
>> b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf");
>> although it is not in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent
>> ones.
>>
>> * For the race between the buffer flush while tty is being reopened, we
>> have a patch that addresses this issue recently merged for 5.0-rc1:
>> 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()").
>> No Ubuntu kernel currently contains this patch, hence we're hereby
>> submitting the SRU request. The upstream complete patch series for
>> this is in [0].
>>
>> * The approach of both patches are similar - they rely in locking/semaphore
>> to prevent race conditions. Some additional patches are necessary to prevent
>> correlated issues, like preventing a potential deadlock due to bad
>> prioritization in servicing I/O over releasing tty_ldisc_lock() - refer to
>> c96cf923a98d ("tty: Don't block on IO when ldisc change is pending").
>> All the necessary fixes are grouped here in this SRU request.
>>
>> * The symptom of the race condition between the buffer flush and the
>> tty reopen routine is a kernel crash with the following trace:
>>
>>
>> BUG: unable to handle kernel paging request at 0000000000002268
>> IP: [<addr>] n_tty_receive_buf_common+0x6a/0xae0
>> [...]
>> Call Trace:
>> [<addr>] ? kvm_sched_clock_read+0x1e/0x30
>> [<addr>] n_tty_receive_buf2+0x14/0x20
>> [<addr>] flush_to_ldisc+0xd5/0x120
>> [<addr>] process_one_work+0x156/0x400
>> [<addr>] worker_thread+0x11a/0x480
>> [...]
>>
>>
>> * A kernel crash was collected from an user, analysis is present in
>> comment #4 in LP #1791758.
>>
>>
>> [Test Case]
>>
>> * It is not trivial to trigger this fault, but the usual recipe is to keep
>> accessing a machine through SSH (or keep killing getty when in IPMI serial
>> console) and in some way run commands before the terminal is ready in that
>> machine (like hacking some echo into ttySx or pts in an infinite loop).
>>
>> * We have reports of users that could reproduce this issue in their
>> production environment, and with the patches present in this SRU request
>> the problem was fixed.
>>
>>
>> [Regression Potential]
>>
>> * tty subsystem is highly central and patches in that area are always
>> delicate. For example, the upstream series [0] is a re-spin (V6) due to
>> a hard to reproduce issue reported in the PA-RISC architecture, which was
>> found in the V5 iteration [1] but was fixed by the patch c96cf923a98d,
>> present in this SRU request.
>>
>> * The patchset [0] is present in tty-next tree since mid-November, and the
>> patch b027e2298bd5 is available upstream since January/2018 (it's available
>> in both Ubuntu kernels 4.15 and 4.18), so the overall likelihood of
>> regressions is low.
>>
>> * These patches were sniff-tested for the 3 versions (4.4, 4.15 and 4.18)
>> and didn't show any issues.
>>
>>
>> [0] https://marc.info/?l=linux-kernel&m=154103190111795
>> [1] https://marc.info/?l=linux-kernel&m=153737852618183
>>
>>
>> Dmitry Safonov (4):
>>   tty: Drop tty->count on tty_reopen() failure
>>   tty: Hold tty_ldisc_lock() during tty_reopen()
>>   tty: Don't block on IO when ldisc change is pending
>>   tty: Simplify tty->count math in tty_reopen()
>>
>> Gaurav Kohli (1):
>>   tty: fix data race between tty_init_dev and flush of buf
>>
>>  drivers/tty/n_hdlc.c    |  4 ++--
>>  drivers/tty/n_r3964.c   |  2 +-
>>  drivers/tty/n_tty.c     |  8 ++++----
>>  drivers/tty/tty_io.c    | 20 +++++++++++++++++---
>>  drivers/tty/tty_ldisc.c | 11 +++++++++--
>>  include/linux/tty.h     |  9 +++++++++
>>  6 files changed, 42 insertions(+), 12 deletions(-)
>>
> Those are indeed some sensitive changes and a bit intrusive, but they
> are needed to fix the issue and most of them have been around on
> mainline for some time now. I guess we'll also detect issues with
> regression tests if they can be easily broken.
>
> Please note that the required format for the provenance of the patch is:
>
>  (backported from commit <sha1> <upstream repo name>)
> or
>  (cherry-pick from commit <sha1> <upstream repo name>)

no, "cherry picked from commit ..." without the - and with an "ed" ;)

>
> so the "commit" part is missing on those patches. The <upstream repo
> name> can be omitted if they come from upstream. This can be fixed when
> applying, but please keep it in mind for the next submissions :-).
>
>
> Acked-by: Kleber Sacilotto de Souza <[hidden email]>
>
>
>


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: ACK/cmnt: [SRU X] [PATCH 0/5] Line discipline buffer flush/tty_reopen() race fix

Kleber Souza
On 1/9/19 11:10 AM, Stefan Bader wrote:

> On 09.01.19 10:57, Kleber Souza wrote:
>> On 1/8/19 9:18 PM, Guilherme G. Piccoli wrote:
>>> BugLink: https://bugs.launchpad.net/bugs/1791758
>>>
>>> [Impact]
>>>
>>> * Line discipline code is racy when we have buffer being flush while the
>>> tty is being initialized or reinitialized. For the first problem, we have
>>> an upstream patch since January 2018:
>>> b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf");
>>> although it is not in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent
>>> ones.
>>>
>>> * For the race between the buffer flush while tty is being reopened, we
>>> have a patch that addresses this issue recently merged for 5.0-rc1:
>>> 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()").
>>> No Ubuntu kernel currently contains this patch, hence we're hereby
>>> submitting the SRU request. The upstream complete patch series for
>>> this is in [0].
>>>
>>> * The approach of both patches are similar - they rely in locking/semaphore
>>> to prevent race conditions. Some additional patches are necessary to prevent
>>> correlated issues, like preventing a potential deadlock due to bad
>>> prioritization in servicing I/O over releasing tty_ldisc_lock() - refer to
>>> c96cf923a98d ("tty: Don't block on IO when ldisc change is pending").
>>> All the necessary fixes are grouped here in this SRU request.
>>>
>>> * The symptom of the race condition between the buffer flush and the
>>> tty reopen routine is a kernel crash with the following trace:
>>>
>>>
>>> BUG: unable to handle kernel paging request at 0000000000002268
>>> IP: [<addr>] n_tty_receive_buf_common+0x6a/0xae0
>>> [...]
>>> Call Trace:
>>> [<addr>] ? kvm_sched_clock_read+0x1e/0x30
>>> [<addr>] n_tty_receive_buf2+0x14/0x20
>>> [<addr>] flush_to_ldisc+0xd5/0x120
>>> [<addr>] process_one_work+0x156/0x400
>>> [<addr>] worker_thread+0x11a/0x480
>>> [...]
>>>
>>>
>>> * A kernel crash was collected from an user, analysis is present in
>>> comment #4 in LP #1791758.
>>>
>>>
>>> [Test Case]
>>>
>>> * It is not trivial to trigger this fault, but the usual recipe is to keep
>>> accessing a machine through SSH (or keep killing getty when in IPMI serial
>>> console) and in some way run commands before the terminal is ready in that
>>> machine (like hacking some echo into ttySx or pts in an infinite loop).
>>>
>>> * We have reports of users that could reproduce this issue in their
>>> production environment, and with the patches present in this SRU request
>>> the problem was fixed.
>>>
>>>
>>> [Regression Potential]
>>>
>>> * tty subsystem is highly central and patches in that area are always
>>> delicate. For example, the upstream series [0] is a re-spin (V6) due to
>>> a hard to reproduce issue reported in the PA-RISC architecture, which was
>>> found in the V5 iteration [1] but was fixed by the patch c96cf923a98d,
>>> present in this SRU request.
>>>
>>> * The patchset [0] is present in tty-next tree since mid-November, and the
>>> patch b027e2298bd5 is available upstream since January/2018 (it's available
>>> in both Ubuntu kernels 4.15 and 4.18), so the overall likelihood of
>>> regressions is low.
>>>
>>> * These patches were sniff-tested for the 3 versions (4.4, 4.15 and 4.18)
>>> and didn't show any issues.
>>>
>>>
>>> [0] https://marc.info/?l=linux-kernel&m=154103190111795
>>> [1] https://marc.info/?l=linux-kernel&m=153737852618183
>>>
>>>
>>> Dmitry Safonov (4):
>>>   tty: Drop tty->count on tty_reopen() failure
>>>   tty: Hold tty_ldisc_lock() during tty_reopen()
>>>   tty: Don't block on IO when ldisc change is pending
>>>   tty: Simplify tty->count math in tty_reopen()
>>>
>>> Gaurav Kohli (1):
>>>   tty: fix data race between tty_init_dev and flush of buf
>>>
>>>  drivers/tty/n_hdlc.c    |  4 ++--
>>>  drivers/tty/n_r3964.c   |  2 +-
>>>  drivers/tty/n_tty.c     |  8 ++++----
>>>  drivers/tty/tty_io.c    | 20 +++++++++++++++++---
>>>  drivers/tty/tty_ldisc.c | 11 +++++++++--
>>>  include/linux/tty.h     |  9 +++++++++
>>>  6 files changed, 42 insertions(+), 12 deletions(-)
>>>
>> Those are indeed some sensitive changes and a bit intrusive, but they
>> are needed to fix the issue and most of them have been around on
>> mainline for some time now. I guess we'll also detect issues with
>> regression tests if they can be easily broken.
>>
>> Please note that the required format for the provenance of the patch is:
>>
>>  (backported from commit <sha1> <upstream repo name>)
>> or
>>  (cherry-pick from commit <sha1> <upstream repo name>)
> no, "cherry picked from commit ..." without the - and with an "ed" ;)

Thanks for pointing that out. I just copied and pasted from one of our
wiki pages without paying too much attention, I've fixed the wiki page
now :)

>
>> so the "commit" part is missing on those patches. The <upstream repo
>> name> can be omitted if they come from upstream. This can be fixed when
>> applying, but please keep it in mind for the next submissions :-).
>>
>>
>> Acked-by: Kleber Sacilotto de Souza <[hidden email]>
>>
>>
>>


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK/Cmnt: [SRU X] [PATCH 0/5] Line discipline buffer flush/tty_reopen() race fix

Stefan Bader-2
In reply to this post by Guilherme Piccoli
On 08.01.19 21:18, Guilherme G. Piccoli wrote:

> BugLink: https://bugs.launchpad.net/bugs/1791758
>
> [Impact]
>
> * Line discipline code is racy when we have buffer being flush while the
> tty is being initialized or reinitialized. For the first problem, we have
> an upstream patch since January 2018:
> b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf");
> although it is not in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent
> ones.
>
> * For the race between the buffer flush while tty is being reopened, we
> have a patch that addresses this issue recently merged for 5.0-rc1:
> 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()").
> No Ubuntu kernel currently contains this patch, hence we're hereby
> submitting the SRU request. The upstream complete patch series for
> this is in [0].
>
> * The approach of both patches are similar - they rely in locking/semaphore
> to prevent race conditions. Some additional patches are necessary to prevent
> correlated issues, like preventing a potential deadlock due to bad
> prioritization in servicing I/O over releasing tty_ldisc_lock() - refer to
> c96cf923a98d ("tty: Don't block on IO when ldisc change is pending").
> All the necessary fixes are grouped here in this SRU request.
>
> * The symptom of the race condition between the buffer flush and the
> tty reopen routine is a kernel crash with the following trace:
>
>
> BUG: unable to handle kernel paging request at 0000000000002268
> IP: [<addr>] n_tty_receive_buf_common+0x6a/0xae0
> [...]
> Call Trace:
> [<addr>] ? kvm_sched_clock_read+0x1e/0x30
> [<addr>] n_tty_receive_buf2+0x14/0x20
> [<addr>] flush_to_ldisc+0xd5/0x120
> [<addr>] process_one_work+0x156/0x400
> [<addr>] worker_thread+0x11a/0x480
> [...]
>
>
> * A kernel crash was collected from an user, analysis is present in
> comment #4 in LP #1791758.
>
>
> [Test Case]
>
> * It is not trivial to trigger this fault, but the usual recipe is to keep
> accessing a machine through SSH (or keep killing getty when in IPMI serial
> console) and in some way run commands before the terminal is ready in that
> machine (like hacking some echo into ttySx or pts in an infinite loop).
>
> * We have reports of users that could reproduce this issue in their
> production environment, and with the patches present in this SRU request
> the problem was fixed.
>
>
> [Regression Potential]
>
> * tty subsystem is highly central and patches in that area are always
> delicate. For example, the upstream series [0] is a re-spin (V6) due to
> a hard to reproduce issue reported in the PA-RISC architecture, which was
> found in the V5 iteration [1] but was fixed by the patch c96cf923a98d,
> present in this SRU request.
>
> * The patchset [0] is present in tty-next tree since mid-November, and the
> patch b027e2298bd5 is available upstream since January/2018 (it's available
> in both Ubuntu kernels 4.15 and 4.18), so the overall likelihood of
> regressions is low.
>
> * These patches were sniff-tested for the 3 versions (4.4, 4.15 and 4.18)
> and didn't show any issues.
>
>
> [0] https://marc.info/?l=linux-kernel&m=154103190111795
> [1] https://marc.info/?l=linux-kernel&m=153737852618183
>
>
> Dmitry Safonov (4):
>   tty: Drop tty->count on tty_reopen() failure
>   tty: Hold tty_ldisc_lock() during tty_reopen()
>   tty: Don't block on IO when ldisc change is pending
>   tty: Simplify tty->count math in tty_reopen()
>
> Gaurav Kohli (1):
>   tty: fix data race between tty_init_dev and flush of buf
>
>  drivers/tty/n_hdlc.c    |  4 ++--
>  drivers/tty/n_r3964.c   |  2 +-
>  drivers/tty/n_tty.c     |  8 ++++----
>  drivers/tty/tty_io.c    | 20 +++++++++++++++++---
>  drivers/tty/tty_ldisc.c | 11 +++++++++--
>  include/linux/tty.h     |  9 +++++++++
>  6 files changed, 42 insertions(+), 12 deletions(-)
>
Just commenting to repeat the already mentioned fixup of the cherry-pick lines
on commit.

Acked-by: Stefan Bader <[hidden email]>


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

APPLIED/cmt: [SRU X] [PATCH 0/5] Line discipline buffer flush/tty_reopen() race fix

Khaled Elmously
In reply to this post by Guilherme Piccoli
Fixed the provenance lines.


On 2019-01-08 18:18:44 , Guilherme G. Piccoli wrote:

> BugLink: https://bugs.launchpad.net/bugs/1791758
>
> [Impact]
>
> * Line discipline code is racy when we have buffer being flush while the
> tty is being initialized or reinitialized. For the first problem, we have
> an upstream patch since January 2018:
> b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf");
> although it is not in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent
> ones.
>
> * For the race between the buffer flush while tty is being reopened, we
> have a patch that addresses this issue recently merged for 5.0-rc1:
> 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()").
> No Ubuntu kernel currently contains this patch, hence we're hereby
> submitting the SRU request. The upstream complete patch series for
> this is in [0].
>
> * The approach of both patches are similar - they rely in locking/semaphore
> to prevent race conditions. Some additional patches are necessary to prevent
> correlated issues, like preventing a potential deadlock due to bad
> prioritization in servicing I/O over releasing tty_ldisc_lock() - refer to
> c96cf923a98d ("tty: Don't block on IO when ldisc change is pending").
> All the necessary fixes are grouped here in this SRU request.
>
> * The symptom of the race condition between the buffer flush and the
> tty reopen routine is a kernel crash with the following trace:
>
>
> BUG: unable to handle kernel paging request at 0000000000002268
> IP: [<addr>] n_tty_receive_buf_common+0x6a/0xae0
> [...]
> Call Trace:
> [<addr>] ? kvm_sched_clock_read+0x1e/0x30
> [<addr>] n_tty_receive_buf2+0x14/0x20
> [<addr>] flush_to_ldisc+0xd5/0x120
> [<addr>] process_one_work+0x156/0x400
> [<addr>] worker_thread+0x11a/0x480
> [...]
>
>
> * A kernel crash was collected from an user, analysis is present in
> comment #4 in LP #1791758.
>
>
> [Test Case]
>
> * It is not trivial to trigger this fault, but the usual recipe is to keep
> accessing a machine through SSH (or keep killing getty when in IPMI serial
> console) and in some way run commands before the terminal is ready in that
> machine (like hacking some echo into ttySx or pts in an infinite loop).
>
> * We have reports of users that could reproduce this issue in their
> production environment, and with the patches present in this SRU request
> the problem was fixed.
>
>
> [Regression Potential]
>
> * tty subsystem is highly central and patches in that area are always
> delicate. For example, the upstream series [0] is a re-spin (V6) due to
> a hard to reproduce issue reported in the PA-RISC architecture, which was
> found in the V5 iteration [1] but was fixed by the patch c96cf923a98d,
> present in this SRU request.
>
> * The patchset [0] is present in tty-next tree since mid-November, and the
> patch b027e2298bd5 is available upstream since January/2018 (it's available
> in both Ubuntu kernels 4.15 and 4.18), so the overall likelihood of
> regressions is low.
>
> * These patches were sniff-tested for the 3 versions (4.4, 4.15 and 4.18)
> and didn't show any issues.
>
>
> [0] https://marc.info/?l=linux-kernel&m=154103190111795
> [1] https://marc.info/?l=linux-kernel&m=153737852618183
>
>
> Dmitry Safonov (4):
>   tty: Drop tty->count on tty_reopen() failure
>   tty: Hold tty_ldisc_lock() during tty_reopen()
>   tty: Don't block on IO when ldisc change is pending
>   tty: Simplify tty->count math in tty_reopen()
>
> Gaurav Kohli (1):
>   tty: fix data race between tty_init_dev and flush of buf
>
>  drivers/tty/n_hdlc.c    |  4 ++--
>  drivers/tty/n_r3964.c   |  2 +-
>  drivers/tty/n_tty.c     |  8 ++++----
>  drivers/tty/tty_io.c    | 20 +++++++++++++++++---
>  drivers/tty/tty_ldisc.c | 11 +++++++++--
>  include/linux/tty.h     |  9 +++++++++
>  6 files changed, 42 insertions(+), 12 deletions(-)
>
> --
> 2.19.2
>
>
> --
> kernel-team mailing list
> [hidden email]
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team