kernel/drivers/tty/vt/vt_ioctl.c, branch linux-4.1.y

vt: vt_ioctl: use msecs_to_jiffies for time conversion

2015-03-07T03:02:26Z

Converting milliseconds to jiffies by "val * HZ / 1000" is technically OK but msecs_to_jiffies(val) is the cleaner solution and handles all corner cases correctly. This is a minor API consolidation only and should make things more readable. Signed-off-by: Nicholas Mc Guire Signed-off-by: Greg Kroah-Hartman

tty/vt: Return EBUSY if deallocating VT1 and it is busy

2013-06-17T19:37:29Z

Commit 421b40a6286e ("tty/vt: Fix vc_deallocate() lock order") changed the behavior when deallocating VT 1. Previously if trying to deallocate VT1 and it is busy, we would return EBUSY. The commit changed this to return 0 (success). This commit restores the old behavior. Signed-off-by: Ross Lagerwall Tested-by: Mikael Pettersson Acked-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty/vt: Fix vc_deallocate() lock order

2013-05-20T19:15:59Z

Now that the tty port owns the flip buffers and i/o is allowed from the driver even when no tty is attached, the destruction of the tty port (and the flip buffers) must ensure that no outstanding work is pending. Unfortunately, this creates a lock order problem with the console_lock (see attached lockdep report [1] below). For single console deallocation, drop the console_lock prior to port destruction. When multiple console deallocation, defer port destruction until the consoles have been deallocated. tty_port_destroy() is not required if the port has not been used; remove from vc_allocate() failure path. [1] lockdep report from Dave Jones ====================================================== [ INFO: possible circular locking dependency detected ] 3.9.0+ #16 Not tainted ------------------------------------------------------- (agetty)/26163 is trying to acquire lock: blocked: ((&buf->work)){+.+...}, instance: ffff88011c8b0020, at: [] flush_work+0x5/0x2e0 but task is already holding lock: blocked: (console_lock){+.+.+.}, instance: ffffffff81c2fde0, at: [] vt_ioctl+0xb61/0x1230 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (console_lock){+.+.+.}: [] lock_acquire+0xa4/0x210 [] console_lock+0x77/0x80 [] con_flush_chars+0x2d/0x50 [] n_tty_receive_buf+0x122/0x14d0 [] flush_to_ldisc+0x119/0x170 [] process_one_work+0x211/0x700 [] worker_thread+0x11b/0x3a0 [] kthread+0xed/0x100 [] ret_from_fork+0x7c/0xb0 -> #0 ((&buf->work)){+.+...}: [] __lock_acquire+0x193a/0x1c00 [] lock_acquire+0xa4/0x210 [] flush_work+0x4e/0x2e0 [] __cancel_work_timer+0x95/0x130 [] cancel_work_sync+0x10/0x20 [] tty_port_destroy+0x12/0x20 [] vc_deallocate+0xf8/0x110 [] vt_ioctl+0xb6c/0x1230 [] tty_ioctl+0x285/0xd50 [] do_vfs_ioctl+0x305/0x530 [] sys_ioctl+0x81/0xa0 [] system_call_fastpath+0x16/0x1b other info that might help us debug this: [ 6760.076175] Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(console_lock); lock((&buf->work)); lock(console_lock); lock((&buf->work)); *** DEADLOCK *** 1 lock on stack by (agetty)/26163: #0: blocked: (console_lock){+.+.+.}, instance: ffffffff81c2fde0, at: [] vt_ioctl+0xb61/0x1230 stack backtrace: Pid: 26163, comm: (agetty) Not tainted 3.9.0+ #16 Call Trace: [] print_circular_bug+0x200/0x20e [] __lock_acquire+0x193a/0x1c00 [] ? sched_clock+0x9/0x10 [] ? sched_clock+0x9/0x10 [] ? native_sched_clock+0x20/0x80 [] lock_acquire+0xa4/0x210 [] ? flush_work+0x5/0x2e0 [] flush_work+0x4e/0x2e0 [] ? flush_work+0x5/0x2e0 [] ? mark_held_locks+0xbb/0x140 [] ? __free_pages_ok.part.57+0x93/0xc0 [] ? mark_held_locks+0xbb/0x140 [] ? __cancel_work_timer+0x82/0x130 [] __cancel_work_timer+0x95/0x130 [] cancel_work_sync+0x10/0x20 [] tty_port_destroy+0x12/0x20 [] vc_deallocate+0xf8/0x110 [] vt_ioctl+0xb6c/0x1230 [] ? lock_release_holdtime.part.30+0xa1/0x170 [] tty_ioctl+0x285/0xd50 [] ? inode_has_perm.isra.46.constprop.61+0x56/0x80 [] do_vfs_ioctl+0x305/0x530 [] ? selinux_file_ioctl+0x5b/0x110 [] sys_ioctl+0x81/0xa0 [] system_call_fastpath+0x16/0x1b Cc: Dave Jones Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

drivers/tty/vt/vt_ioctl.c: Include for pm_set_vt_switch

2012-11-21T23:19:52Z

C files should include the header files that prototype their functions. This keeps the types in sync, and eliminates warnings from GCC (-Wmissing-prototypes) and Sparse (-Wdecl). Signed-off-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman

vt: fix race in vt_waitactive()

2012-07-26T20:37:02Z

pm_restore_console() is called from the suspend/resume path, and this calls vt_move_to_console(), which calls vt_waitactive(). There's a race in this path which causes the process which requests the suspend to sleep indefinitely waiting for an event which already happened: P1 P2 vt_move_to_console() set_console() schedule_console_callback() vt_waitactive() check n == fg_console +1 console_callback() switch_screen() vt_event_post() // no waiters vt_event_wait() // forever Fix the race by ensuring we're registered for the event before we check if it's already completed. Signed-off-by: Rabin Vincent Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman

vt: push the tty_lock down into the map handling

2012-04-24T23:14:14Z

When we do this it becomes clear the lock we should be holding is the vc lock, and in fact many of our other helpers are properly invoked this way. We don't at this point guarantee not to race the keyboard code but the results of that appear harmless and that was true before we started as well. We now have no users of tty_lock in the console driver... Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman

vt: waitevent is self locked so drop the tty_lock

2012-03-08T19:10:28Z

Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman

vt: push down tioclinux cases

2012-03-08T19:10:27Z

Some of this ventures into selection which is still a complete lost cause. We are not making it any worse. It's completely busted anyway. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman

vt: push down the tty lock so we can see what is left to tackle

2012-03-08T19:10:27Z

At this point we have the tty_lock guarding a couple of oddities, plus the translation and unimap still. We also extend the console_lock in a couple of spots where coverage is wrong and switch vcs_open to use the right lock ! [Fixed the locking issue Jiri reported] Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman

vt:tackle kbd_table

2012-03-08T18:50:35Z

Keyboard struct lifetime is easy, but the locking is not and is completely ignored by the existing code. Tackle this one head on - Make the kbd_table private so we can run down all direct users - Hoick the relevant ioctl handlers into the keyboard layer - Lock them with the keyboard lock so they don't change mid keypress - Add helpers for things like console stop/start so we isolate the poking around properly - Tweak the braille console so it still builds There are a couple of FIXME locking cases left for ioctls that are so hideous they should be addressed in a later patch. After this patch the kbd_table is private and all the keyboard jiggery pokery is in one place. This update fixes speakup and also a memory leak in the original. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman