linux-stable.git/drivers/tty/tty_io.c, branch linux-3.13.y

tty: Set correct tty name in 'active' sysfs attribute

2014-04-22T23:49:20+00:00

commit 723abd87f6e536f1353c8f64f621520bc29523a3 upstream.

The 'active' sysfs attribute should refer to the currently active tty
devices the console is running on, not the currently active console. The
console structure doesn't refer to any device in sysfs, only the tty the
console is running on has. So we need to print out the tty names in
'active', not the console names.

There is one special-case, which is tty0. If the console is directed to
it, we want 'tty0' to show up in the file, so user-space knows that the
messages get forwarded to the active VT. The ->device() callback would
resolve tty0, though. Hence, treat it special and don't call into the VT
layer to resolve it (plymouth is known to depend on it).

Cc: Lennart Poettering 
Cc: Kay Sievers 
Cc: Jiri Slaby 
Signed-off-by: Werner Fink 
Signed-off-by: Hannes Reinecke 
Signed-off-by: David Herrmann 
Signed-off-by: Greg Kroah-Hartman

tty: Reset hupped state on open

2013-11-25T16:56:49+00:00

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: Heorhi Valakhanovich 
Signed-off-by: Peter Hurley 
Cc: stable  # 3.12
Tested-by: Heorhi Valakhanovich 
Signed-off-by: Greg Kroah-Hartman

tty: disassociate_ctty() sends the extra SIGCONT

2013-09-18T01:53:32+00:00

Starting from v3.10 (probably commit f91e2590410b: "tty: Signal
foreground group processes in hangup") disassociate_ctty() sends SIGCONT
if tty && on_exit.  This breaks LSB test-suite, in particular test8 in
_exit.c and test40 in sigcon5.c.

Put the "!on_exit" check back to restore the old behaviour.

Review by Peter Hurley:
 "Yes, this regression was introduced by me in that commit.  The effect
  of the regression is that ptys will receive a SIGCONT when, in similar
  circumstances, ttys would not.

  The fact that two test vectors accidentally tripped over this
  regression suggests that some other apps may as well.

  Thanks for catching this"

Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Oleg Nesterov 
Reported-by: Karel Srot 
Reviewed-by: Peter Hurley 
Signed-off-by: Linus Torvalds

tty: Only hangup once

2013-08-02T03:47:42+00:00

Instrumented testing shows a tty can be hungup multiple times [1].
Although concurrent hangups are properly serialized, multiple
hangups for the same tty should be prevented.

If tty has already been HUPPED, abort hangup. Note it is not
necessary to cleanup file *redirect on subsequent hangups,
as only TIOCCONS can set that value and ioctls are disabled
after hangup.

[1]
Test performed by simulating a concurrent async hangup via
tty_hangup() with a sync hangup via tty_vhangup(), while
__tty_hangup() was instrumented with:

	diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
	index 26bb78c..fe8b061 100644
	--- a/drivers/tty/tty_io.c
	+++ b/drivers/tty/tty_io.c
	@@ -629,6 +629,8 @@ static void __tty_hangup(struct tty_struct *tty, int exit_session)

		tty_lock(tty);

	+	WARN_ON(test_bit(TTY_HUPPED, &tty->flags));
	+
		/* some functions below drop BTM, so we need this bit */
		set_bit(TTY_HUPPING, &tty->flags);

Test result:

WARNING: at /home/peter/src/kernels/mainline/drivers/tty/tty_io.c:632 __tty_hangup+0x459/0x460()
Modules linked in: ip6table_filter ip6_tables ebtable_nat <...snip...>
CPU: 6 PID: 1197 Comm: kworker/6:2 Not tainted 3.10.0-0+rfcomm-xeon #0+rfcomm
Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 04/30/2012
Workqueue: events do_tty_hangup
 0000000000000009 ffff8802b16d7d18 ffffffff816b553e ffff8802b16d7d58
 ffffffff810407e0 ffff880254f95c00 ffff880254f95c00 ffff8802bfd92b00
 ffff8802bfd96b00 ffff880254f95e40 0000000000000180 ffff8802b16d7d68
Call Trace:
 [] dump_stack+0x19/0x1b
 [] warn_slowpath_common+0x70/0xa0
 [] warn_slowpath_null+0x1a/0x20
 [] __tty_hangup+0x459/0x460
 [] ? finish_task_switch+0xbc/0xe0
 [] do_tty_hangup+0x17/0x20
 [] process_one_work+0x16f/0x450
 [] process_scheduled_works+0x2c/0x40
 [] worker_thread+0x26a/0x380
 [] ? rescuer_thread+0x310/0x310
 [] kthread+0xc0/0xd0
 [] ? destroy_compound_page+0x65/0x92
 [] ? kthread_create_on_node+0x130/0x130
 [] ret_from_fork+0x7c/0xb0
 [] ? kthread_create_on_node+0x130/0x130
---[ end trace 98d9f01536cf411e ]---

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

tty: Fix lock order in tty_do_resize()

2013-07-24T22:12:53+00:00

Commits 6a1c0680cf3ba94356ecd58833e1540c93472a57 and
9356b535fcb71db494fc434acceb79f56d15bda2, respectively
  'tty: Convert termios_mutex to termios_rwsem' and
  'n_tty: Access termios values safely'
introduced a circular lock dependency with console_lock and
termios_rwsem.

The lockdep report [1] shows that n_tty_write() will attempt
to claim console_lock while holding the termios_rwsem, whereas
tty_do_resize() may already hold the console_lock while
claiming the termios_rwsem.

Since n_tty_write() and tty_do_resize() do not contend
over the same data -- the tty->winsize structure -- correct
the lock dependency by introducing a new lock which
specifically serializes access to tty->winsize only.

[1] Lockdep report

======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
-------------------------------------------------------
modprobe/277 is trying to acquire lock:
 (&tty->termios_rwsem){++++..}, at: [] tty_do_resize+0x36/0xe0

but task is already holding lock:
 ((fb_notifier_list).rwsem){.+.+.+}, at: [] __blocking_notifier_call_chain+0x56/0xc0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 ((fb_notifier_list).rwsem){.+.+.+}:
       [] lock_acquire+0x92/0x1f0
       [] down_read+0x47/0x5c
       [] __blocking_notifier_call_chain+0x56/0xc0
       [] blocking_notifier_call_chain+0x16/0x20
       [] fb_notifier_call_chain+0x1b/0x20
       [] register_framebuffer+0x1e2/0x320
       [] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
       [] nouveau_fbcon_init+0x105/0x140 [nouveau]
       [] nouveau_drm_load+0x43f/0x610 [nouveau]
       [] drm_get_pci_dev+0x17e/0x2a0 [drm]
       [] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
       [] local_pci_probe+0x4b/0x80
       [] pci_device_probe+0x111/0x120
       [] driver_probe_device+0x8b/0x3a0
       [] __driver_attach+0xab/0xb0
       [] bus_for_each_dev+0x5d/0xa0
       [] driver_attach+0x1e/0x20
       [] bus_add_driver+0x111/0x290
       [] driver_register+0x77/0x170
       [] __pci_register_driver+0x64/0x70
       [] drm_pci_init+0x11a/0x130 [drm]
       [] nouveau_drm_init+0x4d/0x1000 [nouveau]
       [] do_one_initcall+0xea/0x1a0
       [] load_module+0x123b/0x1bf0
       [] SyS_init_module+0xd7/0x120
       [] system_call_fastpath+0x16/0x1b

-> #1 (console_lock){+.+.+.}:
       [] lock_acquire+0x92/0x1f0
       [] console_lock+0x77/0x80
       [] con_flush_chars+0x31/0x50
       [] n_tty_write+0x1ec/0x4d0
       [] tty_write+0x159/0x2e0
       [] redirected_tty_write+0xb5/0xc0
       [] vfs_write+0xc5/0x1f0
       [] SyS_write+0x55/0xa0
       [] system_call_fastpath+0x16/0x1b

-> #0 (&tty->termios_rwsem){++++..}:
       [] __lock_acquire+0x1c43/0x1d30
       [] lock_acquire+0x92/0x1f0
       [] down_write+0x44/0x70
       [] tty_do_resize+0x36/0xe0
       [] vc_do_resize+0x3e1/0x4c0
       [] vc_resize+0x1f/0x30
       [] fbcon_init+0x385/0x5a0
       [] visual_init+0xbc/0x120
       [] do_bind_con_driver+0x163/0x320
       [] do_take_over_console+0x61/0x70
       [] do_fbcon_takeover+0x63/0xc0
       [] fbcon_event_notify+0x715/0x820
       [] notifier_call_chain+0x5d/0x110
       [] __blocking_notifier_call_chain+0x6c/0xc0
       [] blocking_notifier_call_chain+0x16/0x20
       [] fb_notifier_call_chain+0x1b/0x20
       [] register_framebuffer+0x1e2/0x320
       [] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
       [] nouveau_fbcon_init+0x105/0x140 [nouveau]
       [] nouveau_drm_load+0x43f/0x610 [nouveau]
       [] drm_get_pci_dev+0x17e/0x2a0 [drm]
       [] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
       [] local_pci_probe+0x4b/0x80
       [] pci_device_probe+0x111/0x120
       [] driver_probe_device+0x8b/0x3a0
       [] __driver_attach+0xab/0xb0
       [] bus_for_each_dev+0x5d/0xa0
       [] driver_attach+0x1e/0x20
       [] bus_add_driver+0x111/0x290
       [] driver_register+0x77/0x170
       [] __pci_register_driver+0x64/0x70
       [] drm_pci_init+0x11a/0x130 [drm]
       [] nouveau_drm_init+0x4d/0x1000 [nouveau]
       [] do_one_initcall+0xea/0x1a0
       [] load_module+0x123b/0x1bf0
       [] SyS_init_module+0xd7/0x120
       [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

Chain exists of:
  &tty->termios_rwsem --> console_lock --> (fb_notifier_list).rwsem

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((fb_notifier_list).rwsem);
                               lock(console_lock);
                               lock((fb_notifier_list).rwsem);
  lock(&tty->termios_rwsem);

 *** DEADLOCK ***

7 locks held by modprobe/277:
 #0:  (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x5b/0xb0
 #1:  (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x69/0xb0
 #2:  (drm_global_mutex){+.+.+.}, at: [] drm_get_pci_dev+0xbd/0x2a0 [drm]
 #3:  (registration_lock){+.+.+.}, at: [] register_framebuffer+0x25/0x320
 #4:  (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x26/0x60
 #5:  (console_lock){+.+.+.}, at: [] register_framebuffer+0x1d4/0x320
 #6:  ((fb_notifier_list).rwsem){.+.+.+}, at: [] __blocking_notifier_call_chain+0x56/0xc0

stack backtrace:
CPU: 0 PID: 277 Comm: modprobe Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 04/30/2012
 ffffffff8213e5e0 ffff8802aa2fb298 ffffffff81755f19 ffff8802aa2fb2e8
 ffffffff8174f506 ffff8802aa2fa000 ffff8802aa2fb378 ffff8802aa2ea8e8
 ffff8802aa2ea910 ffff8802aa2ea8e8 0000000000000006 0000000000000007
Call Trace:
 [] dump_stack+0x19/0x1b
 [] print_circular_bug+0x1fb/0x20c
 [] __lock_acquire+0x1c43/0x1d30
 [] ? mark_held_locks+0xae/0x120
 [] ? trace_hardirqs_on_caller+0x105/0x1d0
 [] lock_acquire+0x92/0x1f0
 [] ? tty_do_resize+0x36/0xe0
 [] down_write+0x44/0x70
 [] ? tty_do_resize+0x36/0xe0
 [] tty_do_resize+0x36/0xe0
 [] vc_do_resize+0x3e1/0x4c0
 [] vc_resize+0x1f/0x30
 [] fbcon_init+0x385/0x5a0
 [] visual_init+0xbc/0x120
 [] do_bind_con_driver+0x163/0x320
 [] do_take_over_console+0x61/0x70
 [] do_fbcon_takeover+0x63/0xc0
 [] fbcon_event_notify+0x715/0x820
 [] notifier_call_chain+0x5d/0x110
 [] __blocking_notifier_call_chain+0x6c/0xc0
 [] blocking_notifier_call_chain+0x16/0x20
 [] fb_notifier_call_chain+0x1b/0x20
 [] register_framebuffer+0x1e2/0x320
 [] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
 [] ? kmemleak_alloc+0x5b/0xc0
 [] ? kmem_cache_alloc_trace+0x104/0x290
 [] ? drm_fb_helper_single_add_all_connectors+0x81/0xf0 [drm_kms_helper]
 [] nouveau_fbcon_init+0x105/0x140 [nouveau]
 [] nouveau_drm_load+0x43f/0x610 [nouveau]
 [] drm_get_pci_dev+0x17e/0x2a0 [drm]
 [] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
 [] ? _raw_spin_unlock_irqrestore+0x42/0x80
 [] local_pci_probe+0x4b/0x80
 [] pci_device_probe+0x111/0x120
 [] driver_probe_device+0x8b/0x3a0
 [] __driver_attach+0xab/0xb0
 [] ? driver_probe_device+0x3a0/0x3a0
 [] bus_for_each_dev+0x5d/0xa0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x111/0x290
 [] ? 0xffffffffa0229fff
 [] driver_register+0x77/0x170
 [] ? 0xffffffffa0229fff
 [] __pci_register_driver+0x64/0x70
 [] drm_pci_init+0x11a/0x130 [drm]
 [] ? 0xffffffffa0229fff
 [] ? 0xffffffffa0229fff
 [] nouveau_drm_init+0x4d/0x1000 [nouveau]
 [] do_one_initcall+0xea/0x1a0
 [] load_module+0x123b/0x1bf0
 [] ? ddebug_proc_open+0xb0/0xb0
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [] SyS_init_module+0xd7/0x120
 [] system_call_fastpath+0x16/0x1b

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

n_tty: Fix EOF push handling

2013-07-24T00:08:40+00:00

In canonical mode, an EOF which is not the first character of the line
causes read() to complete and return the number of characters read so
far (commonly referred to as EOF push). However, if the previous read()
returned because the user buffer was full _and_ the next character
is an EOF not at the beginning of the line, read() must not return 0,
thus mistakenly indicating the end-of-file condition.

The TTY_PUSH flag is used to indicate an EOF was received which is not
at the beginning of the line. Because the EOF push condition is
evaluated by a thread other than the read(), multiple EOF pushes can
cause a premature end-of-file to be indicated.

Instead, discover the 'EOF push as first read character' condition
from the read() thread itself, and restart the i/o loop if detected.

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

tty: Only guarantee termios read safety for throttle/unthrottle

2013-07-23T23:43:02+00:00

No tty driver modifies termios during throttle() or unthrottle().
Therefore, only read safety is required.

However, tty_throttle_safe and tty_unthrottle_safe must still be
mutually exclusive; introduce throttle_mutex for that purpose.

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

tty: Convert termios_mutex to termios_rwsem

2013-07-23T23:43:01+00:00

termios is commonly accessed unsafely (especially by N_TTY)
because the existing mutex forces exclusive access.
Convert existing usage.

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

tty: Replace ldisc locking with ldisc_sem

2013-07-23T23:38:34+00:00

Line discipline locking was performed with a combination of
a mutex, a status bit, a count, and a waitqueue -- basically,
a rw semaphore.

Replace the existing combination with an ld_semaphore.

Fixes:
 1) the 'reference acquire after ldisc locked' bug
 2) the over-complicated halt mechanism
 3) lock order wrt. tty_lock()
 4) dropping locks while changing ldisc
 5) previously unidentified deadlock while locking ldisc from
    both linked ttys concurrently
 6) previously unidentified recursive deadlocks

Adds much-needed lockdep diagnostics.

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

tty: Fix tty_ldisc_lock name collision

2013-07-23T23:38:34+00:00

The file scope spinlock identifier, tty_ldisc_lock, will collide
with the file scope lock function tty_ldisc_lock() so rename it.

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