<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/tty/tty_io.c, branch v4.14.217</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.217</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.217'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-12-11T12:39:04+00:00</updated>
<entry>
<title>tty: Fix -&gt;session locking</title>
<updated>2020-12-11T12:39:04+00:00</updated>
<author>
<name>Jann Horn</name>
<email>jannh@google.com</email>
</author>
<published>2020-12-03T01:25:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8deb3d9018400fab0a7401a910d3341053f5ec82'/>
<id>urn:sha1:8deb3d9018400fab0a7401a910d3341053f5ec82</id>
<content type='text'>
commit c8bcd9c5be24fb9e6132e97da5a35e55a83e36b9 upstream.

Currently, locking of -&gt;session is very inconsistent; most places
protect it using the legacy tty mutex, but disassociate_ctty(),
__do_SAK(), tiocspgrp() and tiocgsid() don't.
Two of the writers hold the ctrl_lock (because they already need it for
-&gt;pgrp), but __proc_set_tty() doesn't do that yet.

On a PREEMPT=y system, an unprivileged user can theoretically abuse
this broken locking to read 4 bytes of freed memory via TIOCGSID if
tiocgsid() is preempted long enough at the right point. (Other things
might also go wrong, especially if root-only ioctls are involved; I'm
not sure about that.)

Change the locking on -&gt;session such that:

 - tty_lock() is held by all writers: By making disassociate_ctty()
   hold it. This should be fine because the same lock can already be
   taken through the call to tty_vhangup_session().
   The tricky part is that we need to shorten the area covered by
   siglock to be able to take tty_lock() without ugly retry logic; as
   far as I can tell, this should be fine, since nothing in the
   signal_struct is touched in the `if (tty)` branch.
 - ctrl_lock is held by all writers: By changing __proc_set_tty() to
   hold the lock a little longer.
 - All readers that aren't holding tty_lock() hold ctrl_lock: By
   adding locking to tiocgsid() and __do_SAK(), and expanding the area
   covered by ctrl_lock in tiocspgrp().

Cc: stable@kernel.org
Signed-off-by: Jann Horn &lt;jannh@google.com&gt;
Reviewed-by: Jiri Slaby &lt;jirislaby@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: ldisc: add sysctl to prevent autoloading of ldiscs</title>
<updated>2019-04-17T06:37:45+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2019-01-21T16:26:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad2548c9462f1aa41ddb8b7f61afeb418e64cec7'/>
<id>urn:sha1:ad2548c9462f1aa41ddb8b7f61afeb418e64cec7</id>
<content type='text'>
commit 7c0cca7c847e6e019d67b7d793efbbe3b947d004 upstream.

By default, the kernel will automatically load the module of any line
dicipline that is asked for.  As this sometimes isn't the safest thing
to do, provide a sysctl to disable this feature.

By default, we set this to 'y' as that is the historical way that Linux
has worked, and we do not want to break working systems.  But in the
future, perhaps this can default to 'n' to prevent this functionality.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: Handle problem if line discipline does not have receive_buf</title>
<updated>2019-01-31T07:13:43+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2019-01-20T09:46:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a358f0becce04eed99eb50111f4cc22b25792de8'/>
<id>urn:sha1:a358f0becce04eed99eb50111f4cc22b25792de8</id>
<content type='text'>
commit 27cfb3a53be46a54ec5e0bd04e51995b74c90343 upstream.

Some tty line disciplines do not have a receive buf callback, so
properly check for that before calling it.  If they do not have this
callback, just eat the character quietly, as we can't fail this call.

Reported-by: Jann Horn &lt;jannh@google.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: Don't hold ldisc lock in tty_reopen() if ldisc present</title>
<updated>2019-01-23T07:09:45+00:00</updated>
<author>
<name>Dmitry Safonov</name>
<email>dima@arista.com</email>
</author>
<published>2019-01-09T01:17:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cb7f9a466349842d39c2ccb27bd939baf333b6a4'/>
<id>urn:sha1:cb7f9a466349842d39c2ccb27bd939baf333b6a4</id>
<content type='text'>
commit d3736d82e8169768218ee0ef68718875918091a0 upstream.

Try to get reference for ldisc during tty_reopen().
If ldisc present, we don't need to do tty_ldisc_reinit() and lock the
write side for line discipline semaphore.
Effectively, it optimizes fast-path for tty_reopen(), but more
importantly it won't interrupt ongoing IO on the tty as no ldisc change
is needed.
Fixes user-visible issue when tty_reopen() interrupted login process for
user with a long password, observed and reported by Lukas.

Fixes: c96cf923a98d ("tty: Don't block on IO when ldisc change is pending")
Fixes: 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()")
Cc: Jiri Slaby &lt;jslaby@suse.com&gt;
Reported-by: Lukas F. Hartmann &lt;lukas@mntmn.com&gt;
Tested-by: Lukas F. Hartmann &lt;lukas@mntmn.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Dmitry Safonov &lt;dima@arista.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: Simplify tty-&gt;count math in tty_reopen()</title>
<updated>2019-01-23T07:09:45+00:00</updated>
<author>
<name>Dmitry Safonov</name>
<email>dima@arista.com</email>
</author>
<published>2018-11-01T00:24:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4086e2872f72fcc3539dcae9b6daebe29161dfc4'/>
<id>urn:sha1:4086e2872f72fcc3539dcae9b6daebe29161dfc4</id>
<content type='text'>
commit cf62a1a13749db0d32b5cdd800ea91a4087319de upstream.

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 &lt;jslaby@suse.com&gt;
Link: lkml.kernel.org/r/&lt;20180829022353.23568-2-dima@arista.com&gt;
Suggested-by: Jiri Slaby &lt;jslaby@suse.com&gt;
Reviewed-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Tested-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Dmitry Safonov &lt;dima@arista.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: Hold tty_ldisc_lock() during tty_reopen()</title>
<updated>2019-01-23T07:09:45+00:00</updated>
<author>
<name>Dmitry Safonov</name>
<email>dima@arista.com</email>
</author>
<published>2018-11-01T00:24:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=108bf6a21ee3ea982af8682517afb63f536edcc2'/>
<id>urn:sha1:108bf6a21ee3ea982af8682517afb63f536edcc2</id>
<content type='text'>
commit 83d817f41070c48bc3eb7ec18e43000a548fca5c upstream.

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 &lt;jslaby@suse.com&gt;
Cc: stable@vger.kernel.org # b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf")
Reviewed-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Reported-by: syzbot+3aa9784721dfb90e984d@syzkaller.appspotmail.com
Tested-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Tested-by: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Signed-off-by: Dmitry Safonov &lt;dima@arista.com&gt;
Tested-by: Tycho Andersen &lt;tycho@tycho.ws&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: check name length in tty_find_polling_driver()</title>
<updated>2018-11-21T08:24:03+00:00</updated>
<author>
<name>Miles Chen</name>
<email>miles.chen@mediatek.com</email>
</author>
<published>2018-10-08T02:39:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8c5800cdb75c354ec0224f0fbab9e4c604b065c0'/>
<id>urn:sha1:8c5800cdb75c354ec0224f0fbab9e4c604b065c0</id>
<content type='text'>
[ Upstream commit 33a1a7be198657c8ca26ad406c4d2a89b7162bcc ]

The issue is found by a fuzzing test.
If tty_find_polling_driver() recevies an incorrect input such as
',,' or '0b', the len becomes 0 and strncmp() always return 0.
In this case, a null p-&gt;ops-&gt;poll_init() is called and it causes a kernel
panic.

Fix this by checking name length against zero in tty_find_polling_driver().

$echo ,, &gt; /sys/module/kgdboc/parameters/kgdboc
[   20.804451] WARNING: CPU: 1 PID: 104 at drivers/tty/serial/serial_core.c:457
uart_get_baud_rate+0xe8/0x190
[   20.804917] Modules linked in:
[   20.805317] CPU: 1 PID: 104 Comm: sh Not tainted 4.19.0-rc7ajb #8
[   20.805469] Hardware name: linux,dummy-virt (DT)
[   20.805732] pstate: 20000005 (nzCv daif -PAN -UAO)
[   20.805895] pc : uart_get_baud_rate+0xe8/0x190
[   20.806042] lr : uart_get_baud_rate+0xc0/0x190
[   20.806476] sp : ffffffc06acff940
[   20.806676] x29: ffffffc06acff940 x28: 0000000000002580
[   20.806977] x27: 0000000000009600 x26: 0000000000009600
[   20.807231] x25: ffffffc06acffad0 x24: 00000000ffffeff0
[   20.807576] x23: 0000000000000001 x22: 0000000000000000
[   20.807807] x21: 0000000000000001 x20: 0000000000000000
[   20.808049] x19: ffffffc06acffac8 x18: 0000000000000000
[   20.808277] x17: 0000000000000000 x16: 0000000000000000
[   20.808520] x15: ffffffffffffffff x14: ffffffff00000000
[   20.808757] x13: ffffffffffffffff x12: 0000000000000001
[   20.809011] x11: 0101010101010101 x10: ffffff880d59ff5f
[   20.809292] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
[   20.809549] x7 : 0000000000000000 x6 : ffffff880d59ff5f
[   20.809803] x5 : 0000000080008001 x4 : 0000000000000003
[   20.810056] x3 : ffffff900853e6b4 x2 : dfffff9000000000
[   20.810693] x1 : ffffffc06acffad0 x0 : 0000000000000cb0
[   20.811005] Call trace:
[   20.811214]  uart_get_baud_rate+0xe8/0x190
[   20.811479]  serial8250_do_set_termios+0xe0/0x6f4
[   20.811719]  serial8250_set_termios+0x48/0x54
[   20.811928]  uart_set_options+0x138/0x1bc
[   20.812129]  uart_poll_init+0x114/0x16c
[   20.812330]  tty_find_polling_driver+0x158/0x200
[   20.812545]  configure_kgdboc+0xbc/0x1bc
[   20.812745]  param_set_kgdboc_var+0xb8/0x150
[   20.812960]  param_attr_store+0xbc/0x150
[   20.813160]  module_attr_store+0x40/0x58
[   20.813364]  sysfs_kf_write+0x8c/0xa8
[   20.813563]  kernfs_fop_write+0x154/0x290
[   20.813764]  vfs_write+0xf0/0x278
[   20.813951]  __arm64_sys_write+0x84/0xf4
[   20.814400]  el0_svc_common+0xf4/0x1dc
[   20.814616]  el0_svc_handler+0x98/0xbc
[   20.814804]  el0_svc+0x8/0xc
[   20.822005] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[   20.826913] Mem abort info:
[   20.827103]   ESR = 0x84000006
[   20.827352]   Exception class = IABT (current EL), IL = 16 bits
[   20.827655]   SET = 0, FnV = 0
[   20.827855]   EA = 0, S1PTW = 0
[   20.828135] user pgtable: 4k pages, 39-bit VAs, pgdp = (____ptrval____)
[   20.828484] [0000000000000000] pgd=00000000aadee003, pud=00000000aadee003, pmd=0000000000000000
[   20.829195] Internal error: Oops: 84000006 [#1] SMP
[   20.829564] Modules linked in:
[   20.829890] CPU: 1 PID: 104 Comm: sh Tainted: G        W         4.19.0-rc7ajb #8
[   20.830545] Hardware name: linux,dummy-virt (DT)
[   20.830829] pstate: 60000085 (nZCv daIf -PAN -UAO)
[   20.831174] pc :           (null)
[   20.831457] lr : serial8250_do_set_termios+0x358/0x6f4
[   20.831727] sp : ffffffc06acff9b0
[   20.831936] x29: ffffffc06acff9b0 x28: ffffff9008d7c000
[   20.832267] x27: ffffff900969e16f x26: 0000000000000000
[   20.832589] x25: ffffff900969dfb0 x24: 0000000000000000
[   20.832906] x23: ffffffc06acffad0 x22: ffffff900969e160
[   20.833232] x21: 0000000000000000 x20: ffffffc06acffac8
[   20.833559] x19: ffffff900969df90 x18: 0000000000000000
[   20.833878] x17: 0000000000000000 x16: 0000000000000000
[   20.834491] x15: ffffffffffffffff x14: ffffffff00000000
[   20.834821] x13: ffffffffffffffff x12: 0000000000000001
[   20.835143] x11: 0101010101010101 x10: ffffff880d59ff5f
[   20.835467] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
[   20.835790] x7 : 0000000000000000 x6 : ffffff880d59ff5f
[   20.836111] x5 : c06419717c314100 x4 : 0000000000000007
[   20.836419] x3 : 0000000000000000 x2 : 0000000000000000
[   20.836732] x1 : 0000000000000001 x0 : ffffff900969df90
[   20.837100] Process sh (pid: 104, stack limit = 0x(____ptrval____))
[   20.837396] Call trace:
[   20.837566]            (null)
[   20.837816]  serial8250_set_termios+0x48/0x54
[   20.838089]  uart_set_options+0x138/0x1bc
[   20.838570]  uart_poll_init+0x114/0x16c
[   20.838834]  tty_find_polling_driver+0x158/0x200
[   20.839119]  configure_kgdboc+0xbc/0x1bc
[   20.839380]  param_set_kgdboc_var+0xb8/0x150
[   20.839658]  param_attr_store+0xbc/0x150
[   20.839920]  module_attr_store+0x40/0x58
[   20.840183]  sysfs_kf_write+0x8c/0xa8
[   20.840183]  sysfs_kf_write+0x8c/0xa8
[   20.840440]  kernfs_fop_write+0x154/0x290
[   20.840702]  vfs_write+0xf0/0x278
[   20.840942]  __arm64_sys_write+0x84/0xf4
[   20.841209]  el0_svc_common+0xf4/0x1dc
[   20.841471]  el0_svc_handler+0x98/0xbc
[   20.841713]  el0_svc+0x8/0xc
[   20.842057] Code: bad PC value
[   20.842764] ---[ end trace a8835d7de79aaadf ]---
[   20.843134] Kernel panic - not syncing: Fatal exception
[   20.843515] SMP: stopping secondary CPUs
[   20.844289] Kernel Offset: disabled
[   20.844634] CPU features: 0x0,21806002
[   20.844857] Memory Limit: none
[   20.845172] ---[ end Kernel panic - not syncing: Fatal exception ]---

Signed-off-by: Miles Chen &lt;miles.chen@mediatek.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: Drop tty-&gt;count on tty_reopen() failure</title>
<updated>2018-10-13T07:27:26+00:00</updated>
<author>
<name>Dmitry Safonov</name>
<email>dima@arista.com</email>
</author>
<published>2018-09-17T23:52:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=171f90d4ae841e2205fb706b49f266d40207d0bb'/>
<id>urn:sha1:171f90d4ae841e2205fb706b49f266d40207d0bb</id>
<content type='text'>
commit fe32416790093b31364c08395727de17ec96ace1 upstream.

In case of tty_ldisc_reinit() failure, tty-&gt;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-&gt;count(10529) != (#fd's(7) + #kopen's(0))

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

Cc: stable@vger.kernel.org # v4.6+
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Jiri Slaby &lt;jslaby@suse.com&gt;
Reviewed-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Tested-by: Jiri Slaby &lt;jslaby@suse.com&gt;
Tested-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Tested-by: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Signed-off-by: Dmitry Safonov &lt;dima@arista.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: Don't call panic() at tty_ldisc_init()</title>
<updated>2018-05-01T19:58:13+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2018-04-05T10:40:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4854b9665c8193291199e7b3d53c63a14a19a802'/>
<id>urn:sha1:4854b9665c8193291199e7b3d53c63a14a19a802</id>
<content type='text'>
commit 903f9db10f18f735e62ba447147b6c434b6af003 upstream.

syzbot is reporting kernel panic [1] triggered by memory allocation failure
at tty_ldisc_get() from tty_ldisc_init(). But since both tty_ldisc_get()
and caller of tty_ldisc_init() can cleanly handle errors, tty_ldisc_init()
does not need to call panic() when tty_ldisc_get() failed.

[1] https://syzkaller.appspot.com/bug?id=883431818e036ae6a9981156a64b821110f39187

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Jiri Slaby &lt;jslaby@suse.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: make n_tty_read() always abort if hangup is in progress</title>
<updated>2018-04-24T07:36:21+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2018-02-13T15:38:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9427a4aecf2330ba70dd59f194416de3e49042e2'/>
<id>urn:sha1:9427a4aecf2330ba70dd59f194416de3e49042e2</id>
<content type='text'>
commit 28b0f8a6962a24ed21737578f3b1b07424635c9e upstream.

A tty is hung up by __tty_hangup() setting file-&gt;f_op to
hung_up_tty_fops, which is skipped on ttys whose write operation isn't
tty_write().  This means that, for example, /dev/console whose write
op is redirected_tty_write() is never actually marked hung up.

Because n_tty_read() uses the hung up status to decide whether to
abort the waiting readers, the lack of hung-up marking can lead to the
following scenario.

 1. A session contains two processes.  The leader and its child.  The
    child ignores SIGHUP.

 2. The leader exits and starts disassociating from the controlling
    terminal (/dev/console).

 3. __tty_hangup() skips setting f_op to hung_up_tty_fops.

 4. SIGHUP is delivered and ignored.

 5. tty_ldisc_hangup() is invoked.  It wakes up the waits which should
    clear the read lockers of tty-&gt;ldisc_sem.

 6. The reader wakes up but because tty_hung_up_p() is false, it
    doesn't abort and goes back to sleep while read-holding
    tty-&gt;ldisc_sem.

 7. The leader progresses to tty_ldisc_lock() in tty_ldisc_hangup()
    and is now stuck in D sleep indefinitely waiting for
    tty-&gt;ldisc_sem.

The following is Alan's explanation on why some ttys aren't hung up.

 http://lkml.kernel.org/r/20171101170908.6ad08580@alans-desktop

 1. It broke the serial consoles because they would hang up and close
    down the hardware. With tty_port that *should* be fixable properly
    for any cases remaining.

 2. The console layer was (and still is) completely broken and doens't
    refcount properly. So if you turn on console hangups it breaks (as
    indeed does freeing consoles and half a dozen other things).

As neither can be fixed quickly, this patch works around the problem
by introducing a new flag, TTY_HUPPING, which is used solely to tell
n_tty_read() that hang-up is in progress for the console and the
readers should be aborted regardless of the hung-up status of the
device.

The following is a sample hung task warning caused by this issue.

  INFO: task agetty:2662 blocked for more than 120 seconds.
        Not tainted 4.11.3-dbg-tty-lockup-02478-gfd6c7ee-dirty #28
  "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      0  2662      1 0x00000086
  Call Trace:
   __schedule+0x267/0x890
   schedule+0x36/0x80
   schedule_timeout+0x23c/0x2e0
   ldsem_down_write+0xce/0x1f6
   tty_ldisc_lock+0x16/0x30
   tty_ldisc_hangup+0xb3/0x1b0
   __tty_hangup+0x300/0x410
   disassociate_ctty+0x6c/0x290
   do_exit+0x7ef/0xb00
   do_group_exit+0x3f/0xa0
   get_signal+0x1b3/0x5d0
   do_signal+0x28/0x660
   exit_to_usermode_loop+0x46/0x86
   do_syscall_64+0x9c/0xb0
   entry_SYSCALL64_slow_path+0x25/0x25

The following is the repro.  Run "$PROG /dev/console".  The parent
process hangs in D state.

  #include &lt;sys/types.h&gt;
  #include &lt;sys/stat.h&gt;
  #include &lt;sys/wait.h&gt;
  #include &lt;sys/ioctl.h&gt;
  #include &lt;fcntl.h&gt;
  #include &lt;unistd.h&gt;
  #include &lt;stdio.h&gt;
  #include &lt;stdlib.h&gt;
  #include &lt;errno.h&gt;
  #include &lt;signal.h&gt;
  #include &lt;time.h&gt;
  #include &lt;termios.h&gt;

  int main(int argc, char **argv)
  {
	  struct sigaction sact = { .sa_handler = SIG_IGN };
	  struct timespec ts1s = { .tv_sec = 1 };
	  pid_t pid;
	  int fd;

	  if (argc &lt; 2) {
		  fprintf(stderr, "test-hung-tty /dev/$TTY\n");
		  return 1;
	  }

	  /* fork a child to ensure that it isn't already the session leader */
	  pid = fork();
	  if (pid &lt; 0) {
		  perror("fork");
		  return 1;
	  }

	  if (pid &gt; 0) {
		  /* top parent, wait for everyone */
		  while (waitpid(-1, NULL, 0) &gt;= 0)
			  ;
		  if (errno != ECHILD)
			  perror("waitpid");
		  return 0;
	  }

	  /* new session, start a new session and set the controlling tty */
	  if (setsid() &lt; 0) {
		  perror("setsid");
		  return 1;
	  }

	  fd = open(argv[1], O_RDWR);
	  if (fd &lt; 0) {
		  perror("open");
		  return 1;
	  }

	  if (ioctl(fd, TIOCSCTTY, 1) &lt; 0) {
		  perror("ioctl");
		  return 1;
	  }

	  /* fork a child, sleep a bit and exit */
	  pid = fork();
	  if (pid &lt; 0) {
		  perror("fork");
		  return 1;
	  }

	  if (pid &gt; 0) {
		  nanosleep(&amp;ts1s, NULL);
		  printf("Session leader exiting\n");
		  exit(0);
	  }

	  /*
	   * The child ignores SIGHUP and keeps reading from the controlling
	   * tty.  Because SIGHUP is ignored, the child doesn't get killed on
	   * parent exit and the bug in n_tty makes the read(2) block the
	   * parent's control terminal hangup attempt.  The parent ends up in
	   * D sleep until the child is explicitly killed.
	   */
	  sigaction(SIGHUP, &amp;sact, NULL);
	  printf("Child reading tty\n");
	  while (1) {
		  char buf[1024];

		  if (read(fd, buf, sizeof(buf)) &lt; 0) {
			  perror("read");
			  return 1;
		  }
	  }

	  return 0;
  }

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Alan Cox &lt;alan@llwyncelyn.cymru&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
