If vc->vc_uni_pagedir_loc is not NULL, its refcount needs to be
decreased before vc_uni_pagedir_loc is re-assigned.

unreferenced object 0xffff88002cdd13b0 (size 512):
  comm "setfont", pid 503, jiffies 4294896503 (age 722.828s)
  hex dump (first 32 bytes):
    40 92 61 2b 00 88 ff ff 00 00 00 00 00 00 00 00  @.a+............
    00 00 00 00 00 00 00 00 a0 ad 61 2b 00 88 ff ff  ..........a+....
  backtrace:
    [<ffffffff817b755e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff811d4898>] kmem_cache_alloc_trace+0x1c8/0x240
    [<ffffffff814ae7d3>] con_do_clear_unimap.isra.2+0x83/0xe0
    [<ffffffff814ae9b2>] con_clear_unimap+0x22/0x40
    [<ffffffff814a8db8>] vt_ioctl+0xeb8/0x1170
    [<ffffffff8149b458>] tty_ioctl+0x208/0xca0
    [<ffffffff81207858>] do_vfs_ioctl+0x2f8/0x510
    [<ffffffff81207af1>] SyS_ioctl+0x81/0xa0
    [<ffffffff817ca2b2>] system_call_fastpath+0x16/0x75
    [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff88002b619240 (size 256):
  comm "setfont", pid 503, jiffies 4294896503 (age 722.828s)
  hex dump (first 32 bytes):
    90 bc 84 d5 00 88 ff ff 58 85 84 d5 00 88 ff ff  ........X.......
    88 ac 84 d5 00 88 ff ff e0 b1 84 d5 00 88 ff ff  ................
  backtrace:
    [<ffffffff817b755e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff811d4898>] kmem_cache_alloc_trace+0x1c8/0x240
    [<ffffffff814ae286>] con_insert_unipair+0x86/0x170
    [<ffffffff814af107>] con_set_unimap+0x1b7/0x280
    [<ffffffff814a8d65>] vt_ioctl+0xe65/0x1170
    [<ffffffff8149b458>] tty_ioctl+0x208/0xca0
    [<ffffffff81207858>] do_vfs_ioctl+0x2f8/0x510
    [<ffffffff81207af1>] SyS_ioctl+0x81/0xa0
    [<ffffffff817ca2b2>] system_call_fastpath+0x16/0x75
    [<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: NDongxing Zhang <dongxing.zhang@intel.com>
Signed-off-by: NXiaoming Wang <xiaoming.wang@intel.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Tested-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This was introduced in

commit 6db4063c
Author: Antonino A. Daplas <adaplas@gmail.com>
Date:   Mon Jun 26 00:27:12 2006 -0700

    [PATCH] VT binding: Add sysfs control to the VT layer

with the justification

    "In addition, if any of the consoles are in KD_GRAPHICS mode, binding and
    unbinding will not succeed.  KD_GRAPHICS mode usually indicates that the
    underlying console hardware is used for other purposes other than displaying
    text (ie X).  This feature should prevent binding/unbinding from interfering
    with a graphics application using the VT."

I think we should lift this artificial restriction though:
- KD_GRAPHICS doesn't get cleaned up automatically, which means it's
  easy to have terminals stuck in KD_GRAPHICS when hacking around on
  X.
- X doesn't really care, especially with drm where kms already blocks
  fbdev (and hence fbcon) when there's an active compositor.
- This is a root-only interface with a separate .config option and
  it's possible to hang your machine already anyway if you
  unload/reload drivers and don't know what you're doing.

With this patch i915.ko module reloading works again reliably,
something in the recent fedora upgrades broke things.

Cc: Antonino A. Daplas <adaplas@gmail.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently there is a lock order problem between the console lock and the
kernfs s_active lock of the console driver's bind sysfs entry. When
writing to the sysfs entry the lock order is first s_active then console
lock, when unregistering the console driver via
do_unregister_con_driver() the order is the opposite. See the below
bugzilla reference for one instance of a lockdep backtrace.

Fix this by unregistering the console driver from a deferred work, where
we can safely drop the console lock while unregistering the device and
corresponding sysfs entries (which in turn acquire s_active). Note that
we have to keep the console driver slot in the registered_con_driver
array reserved for the driver that's being unregistered until it's fully
removed. Otherwise a concurrent call to do_register_con_driver could
try to reuse the same slot and fail when registering the corresponding
device with a minor index that's still in use.

Note that the referenced bug report contains two dmesg logs with two
distinct lockdep reports: [1] is about a locking scenario involving
s_active, console_lock and the fb_notifier list lock, while [2] is
about a locking scenario involving only s_active and console_lock.
In [1] locking fb_notifier triggers the lockdep warning only because
of its dependence on console_lock, otherwise case [1] is the same
s_active<->console_lock dependency problem fixed by this patch.
Before this change we have the following locking scenarios involving
the 3 locks:

a) via do_unregister_framebuffer()->...->do_unregister_con_driver():
   1. console lock 2. fb_notifier lock 3. s_active lock
b) for example via give_up_console()->do_unregister_con_driver():
   1. console lock 2. s_active lock
c) via vt_bind()/vt_unbind():
   1. s_active lock 2. console lock

Since c) is the console bind sysfs entry's write code path we can't
change the locking order there. We can only fix this issue by removing
s_active's dependence on the other two locks in a) and b). We can do
this only in the vt code which owns the corresponding sysfs entry, so
that after the change we have:

a) 1. console lock 2. fb_notifier lock
b) 1. console lock
c) 1. s_active lock 2. console lock
d) in the new con_driver_unregister_callback():
   1. s_active lock

[1] https://bugs.freedesktop.org/attachment.cgi?id=87716
[2] https://bugs.freedesktop.org/attachment.cgi?id=107602

v2:
- get console_lock earlier in con_driver_unregister_callback(), so we
  protect the following console driver field assignments there
- add code coment explaining the reason for deferring the sysfs entry
  removal
- add a third paragraph to the commit message explaining why there are
  two distinct lockdep reports and that this issue is independent of
  fb/fbcon. (Peter Hurley)
v3:
- clarify further the third paragraph
v4:
- rebased on v4 of patch 1/3
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds until
the next cursor display state toggle, from 50 to 65535. /proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.

Store the interval in the vc_data structure for later access by fbcon,
initializing the value to fbcon's current hardcoded value of 200 msecs.
Signed-off-by: NScot Doyle <lkml14@scotdoyle.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of manual calls of device_create_file() and
device_remove_file(), pass the static attribute groups using
device_create_with_groups().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NNicholas Mc Guire <hofrat@osadl.org>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

this patch fixes following sparse warning:
vt.c:1240:12: warning: symbol 'rgb_from_256' was not declared. Should it be static?
Signed-off-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The vcs device's poll/fasync support relies on the vt notifier to signal
changes to the screen content.  Notifier invocations were missing for
changes that comes through the selection interface though.  Fix that.

Tested with BRLTTY 5.2.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Cc: Dave Mielke <dave@mielke.cc>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently vt_bind and vt_unbind access at least the con_driver object
and registered_con_driver array without holding the console lock. Fix
this by locking around the whole function in each case.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The default console driver (conswitchp) and busy drivers bound to a
console (as reported by con_is_bound()) shouldn't be unregistered.
System console drivers (without the CON_DRIVER_FLAG_MODULE flag) can be
unregistered, provided they are neither default nor busy. The current
code checks for the CON_DRIVER_FLAG_INIT flag but this doesn't make
sense: this flag is set for a driver whenever its associated console's
con_startup() function is called, which first happens when the console
driver is registered (so before the console gets bound) and gets cleared
when the console gets unbound. The purpose of this flag is to show if we
need to call con_startup() on a console before we use it.

Based on the above, do_unregister_con_driver() in its current form will
allow unregistering a console driver only if it was never bound, but
will refuse to unregister one that was bound and later unbound.

Fix this by dropping the CON_DRIVER_FLAG_INIT check, allowing
unregistering of any console driver provided that it's not the default
one and it's not busy.

v2:
- reword the third paragraph to clarify how the fix works (Peter Hurley)
v3:
- unchanged
v4:
- Allow unregistering a system console driver too, needed by i915 to
  unregister vgacon. Update commit description accordingly. (Daniel)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert the pr_warning to the more common pr_warn.

Other miscellanea:

o Convert unusual PR_FMT define and uses to pr_fmt
o Remove unnecessary OOM message
o Fix grammar in an error message
o Convert a pr_warning with a KERN_ERR to pr_err
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 68952076 ("vt: Remove
vt_get_kmsg_redirect() from uapi header") fails to compile if
!CONFIG_VT_CONSOLE.

Move macro definition for vt_get_kmsg_redirect() up with file-scope
function declarations.
Reported-by: NJim Davis <jim.epost@gmail.com>
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes sparse warning:
"obsolete struct initializer, use C99 syntax"
Signed-off-by: NPeng Fan <van.freenix@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

vt_get_kmsg_redirect() only has meaning to the console driver as
an alias for calling vt_kmsg_redirect(). Move the macro definition
to the only source file which uses it; remove from uapi/linux/vt.h
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Otherwise the loop will never stop since we don't make any
forward progress. Noticed while breaking this accidentally
in a painful attempt to make vga_con unregistering work.

With this patch we'll bail out on the first attempt, which
at least leaves a useful enough system behind for debugging.
Livelocks on console_lock just aren't fun.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A bunch of issues:
- We should not kick out the default console (which is tracked in
  conswitchp), so check for that.
- Add better error codes so callers can differentiate between "something
  went wrong" and "your driver isn't registered already". i915 needs
  that so it doesn't fall over when reloading the driver and hence
  vga_con is already unregistered.
- There's a mess with the driver flags: What we need to check for is
  that the driver isn't used any more, i.e. unbound completely (FLAG_INIT).
  And not whether it's the boot console or not (which is the only one
  which doesn't have FLAG_MODULE). Otherwise there's no way to kick
  out the boot console, which i915 wants to do to prevent havoc with
  vga_con interferring (which tends to hang machines).

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I don't fully understand the magic of the vt register/unregister
logic, but apparently everything but the inital console (as set
in the conswitchp pointer) is marked with FLAG_MODULE. Which means
if something unregistered the boot vt driver (e.g. i915.ko kicking
out vga_con) there's nothing left when trying to unbind e.g. fbcon
through sysfs.

But in most cases have the dummy console hanging around besides the
boot console, so this test is fairly dubious. What we actually want is
simply a different console than the one we want to unbind.

v2: Correct the commit message to clarify that the dummy console isn't
always around, but only in most cases (David).

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The vc_data.vc_uni_pagedir filed is currently long int, supposedly to
be served generically.  This, however, leads to lots of cast to
pointer, and rather it worsens the readability significantly.

Actually, we have now only a single uni_pagedir map implementation,
and this won't change likely.  So, it'd be much more simple and
error-prone to just use the exact pointer for struct uni_pagedir
instead of long.

Ditto for vc_uni_pagedir_loc.  It's a pointer to the uni_pagedir, thus
it can be changed similarly to the exact type.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Most other mainstream terminals support "xterm256" colours, which means
people sometimes use these blindly without checking capabilities.

Because of hardware limitations of VGA consoles, colours are downgraded to
16 foregrounds and 8 backgrounds.  On fbdev consoles it would be possible
to support them without quality loss, but adding that would require quite a
large amount of code.
Signed-off-by: NAdam Borowski <kilobyte@angband.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These can be used to send commands consisting of an arbitrary string to the
terminal, most often used to set a terminal's window title or to redefine
the colour palette.  Our console doesn't use OSC, unlike everything else,
which can lead to junk being displayed if a process sends such a code
unconditionally.

The rules for termination follow established practice rather than Ecma-48.
Ecma-48 requires the string to use only byte values 0x08..0x0D and
0x20..0x7E, terminated with either ESC \ or 0x9C.  This would disallow using
8-bit characters, which are reasonable for example in window titles.
A widespread idiom is to terminate with 0x07.  The behaviour for other
control characters differs between terminal emulators, I followed libvte and
xterm:
* 0x07 and ESC anything terminate
* nothing else terminates, all 8-bit values including 0x9C are considered a
  part of the string
Signed-off-by: NAdam Borowski <kilobyte@angband.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAdam Borowski <kilobyte@angband.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

\E[3J console code (secure clear screen) needs to update_screen(vc)
in order to write-through blanks into off-screen video memory.

This has been removed accidentally in 3.6 by:

commit 81732c3b
Author: Jean-François Moine <moinejf@free.fr>
Date:   Thu Sep 6 19:24:13 2012 +0200

    tty vt: Fix line garbage in virtual console on command line edition
Signed-off-by: NPetr Písař <petr.pisar@atlas.cz>
Cc: stable <stable@vger.kernel.org> # 3.6
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is not a bug on our side, but a misdesign in ITU T.416, yet with
all popular terminals supporting these codes, people consider this to
be a bug in Linux.  By breaking the design principles behind SGR codes
(gracefully ignoring unsupported ones should not require knowing about
them), 256 colour ones tend to turn blinking on before invoking an
arbitrary unrelated command.

This commit doesn't add such support, merely skips such codes without
ill effects.
Signed-off-by: NAdam Borowski <kilobyte@angband.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

No modern terminal supports them, and SGR 38 conflicts with detecting
xterm-256 colours.  This also makes SGR 39 consistent with other popular
terminals.  Neither are used by ncurses' terminfo.
Signed-off-by: NAdam Borowski <kilobyte@angband.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The virtual console has (undocumented) module parameters to set the
colors for italic and underlined text, but the default text color was
hardcoded for some reason.  This made it impossible to change the color
for startup messages, or to set the default for new virtual consoles.
Add a module parameter for that, and document the entire bunch.

Any hacker who thinks that a command prompt on a "black screen with
white font" is not supicious enough can now use the kernel parameter
vt.color=10 to get a nice, evil green.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

termios is commonly accessed unsafely (especially by N_TTY)
because the existing mutex forces exclusive access.
Convert existing usage.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Impact:
1:convert all remain take_over_console to do_take_over_console
2:update take_over_console to do_take_over_console in comment

Commit dc964189 ("vt: delete unneeded functions
register_con_driver|take_over_console") delete take_over_console,
but forget to convert remain take_over_console's users to new API
do_take_over_console, this patch fix it.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now there is no place use unregister_con_driver,
and we can achieve unregister_con_driver's function
with unregister_con_driver easily, so just delete it
to reduce code size and duplication.
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are only two place use unregister_con_driver now, this patch
convert them to do_unregister_con_driver too, then we can delete
unregister_con_driver whos function can be achieved with do_unregister_con_driver
easily to reduce code size and duplication.
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now there is no place use bind_con_driver,
and do_bind_con_driver can achieve bind_con_driver's
function easily, so just delete it to reduce code size and
duplication.
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is only one place use bind_con_driver now, this patch
convert it to do_bind_con_driver too, then we can delete
bind_con_driver whos function can be replaced by do_bind_con_driver
easily to reduce code size and duplication.
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now there is no place use unbind_con_driver,
and we can achieve unbind_con_driver's function
with do_unbind_con_driver easily, so just delete
it to reduce code size and duplication.
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is only one place use unbind_con_driver, this patch
convert it to do_unbind_con_driver too, then we can delete
unbind_con_driver to reduce code size and duplication.
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now there is no place use register_con_driver|take_over_console,
and we can achieve their function with do_register_con_driver|
do_take_over_console easily, so just delete them to reduce code duplication.
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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 <davej@redhat.com>

 ======================================================
 [ 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: [<ffffffff81062065>] flush_work+0x5/0x2e0

 but task is already holding lock:
 blocked:  (console_lock){+.+.+.}, instance: ffffffff81c2fde0, at: [<ffffffff813bc201>] vt_ioctl+0xb61/0x1230

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 (console_lock){+.+.+.}:
        [<ffffffff810b3f74>] lock_acquire+0xa4/0x210
        [<ffffffff810416c7>] console_lock+0x77/0x80
        [<ffffffff813c3dcd>] con_flush_chars+0x2d/0x50
        [<ffffffff813b32b2>] n_tty_receive_buf+0x122/0x14d0
        [<ffffffff813b7709>] flush_to_ldisc+0x119/0x170
        [<ffffffff81064381>] process_one_work+0x211/0x700
        [<ffffffff8106498b>] worker_thread+0x11b/0x3a0
        [<ffffffff8106ce5d>] kthread+0xed/0x100
        [<ffffffff81601cac>] ret_from_fork+0x7c/0xb0

 -> #0 ((&buf->work)){+.+...}:
        [<ffffffff810b349a>] __lock_acquire+0x193a/0x1c00
        [<ffffffff810b3f74>] lock_acquire+0xa4/0x210
        [<ffffffff810620ae>] flush_work+0x4e/0x2e0
        [<ffffffff81065305>] __cancel_work_timer+0x95/0x130
        [<ffffffff810653b0>] cancel_work_sync+0x10/0x20
        [<ffffffff813b8212>] tty_port_destroy+0x12/0x20
        [<ffffffff813c65e8>] vc_deallocate+0xf8/0x110
        [<ffffffff813bc20c>] vt_ioctl+0xb6c/0x1230
        [<ffffffff813b01a5>] tty_ioctl+0x285/0xd50
        [<ffffffff811ba825>] do_vfs_ioctl+0x305/0x530
        [<ffffffff811baad1>] sys_ioctl+0x81/0xa0
        [<ffffffff81601d59>] 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: [<ffffffff813bc201>] vt_ioctl+0xb61/0x1230
 stack backtrace:
 Pid: 26163, comm: (agetty) Not tainted 3.9.0+ #16
 Call Trace:
  [<ffffffff815edb14>] print_circular_bug+0x200/0x20e
  [<ffffffff810b349a>] __lock_acquire+0x193a/0x1c00
  [<ffffffff8100a269>] ? sched_clock+0x9/0x10
  [<ffffffff8100a269>] ? sched_clock+0x9/0x10
  [<ffffffff8100a200>] ? native_sched_clock+0x20/0x80
  [<ffffffff810b3f74>] lock_acquire+0xa4/0x210
  [<ffffffff81062065>] ? flush_work+0x5/0x2e0
  [<ffffffff810620ae>] flush_work+0x4e/0x2e0
  [<ffffffff81062065>] ? flush_work+0x5/0x2e0
  [<ffffffff810b15db>] ? mark_held_locks+0xbb/0x140
  [<ffffffff8113c8a3>] ? __free_pages_ok.part.57+0x93/0xc0
  [<ffffffff810b15db>] ? mark_held_locks+0xbb/0x140
  [<ffffffff810652f2>] ? __cancel_work_timer+0x82/0x130
  [<ffffffff81065305>] __cancel_work_timer+0x95/0x130
  [<ffffffff810653b0>] cancel_work_sync+0x10/0x20
  [<ffffffff813b8212>] tty_port_destroy+0x12/0x20
  [<ffffffff813c65e8>] vc_deallocate+0xf8/0x110
  [<ffffffff813bc20c>] vt_ioctl+0xb6c/0x1230
  [<ffffffff810aec41>] ? lock_release_holdtime.part.30+0xa1/0x170
  [<ffffffff813b01a5>] tty_ioctl+0x285/0xd50
  [<ffffffff812b00f6>] ? inode_has_perm.isra.46.constprop.61+0x56/0x80
  [<ffffffff811ba825>] do_vfs_ioctl+0x305/0x530
  [<ffffffff812b04db>] ? selinux_file_ioctl+0x5b/0x110
  [<ffffffff811baad1>] sys_ioctl+0x81/0xa0
  [<ffffffff81601d59>] system_call_fastpath+0x16/0x1b

Cc: Dave Jones <davej@redhat.com>
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 81732c3b ("tty vt: Fix line garbage in virtual console on
command line edition") broke insert_char() in multiple ways.  Then
commit b1a925f4 ("tty vt: Fix a regression in command line edition")
partially fixed it.  However, the buffer being moved is still too large
and overflowing beyond the end of the current line, corrupting existing
characters on the next line.

Example test case:

echo -e "abc\nde\x1b[A\x1b[4h \x1b[4l\x1b[B"

Expected result:

ab c
de

Current result:

ab c
 e

Needless to say that this is very annoying when inserting words in the
middle of paragraphs with certain text editors.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Cc: Jean-François Moine <moinejf@free.fr>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I've still got lockdep warnings even after Alan's patch, and it seems that
yet more band aids are required to paper over similar paths for
unbind_con_driver() and unregister_con_driver().  After this hack, lockdep
warnings are finally gone.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: stable <stable@vger.kernel.org>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Adjust the console layer to allow a take over call where the caller
already holds the locks.  Make the fb layer lock in order.

This is partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

[akpm@linux-foundation.org: remove stray non-ascii char, tidy comment]
[akpm@linux-foundation.org: export do_take_over_console()]
[airlied: cleanup another non-ascii char]
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: stable <stable@vger.kernel.org>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When we switch from 256->512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.

The problem case we see is grub2 writes spaces with the bit set, so it
ends up with data like 0x820, which gets reinterpreted into 0x120 char
which the font translates into G with a circumflex. This flashes up on
screen at boot and is quite ugly.

A current side effect of this patch though is that any rendering on the
screen changes color to a slightly darker color, but at least the screen
no longer corrupts.

v2: as suggested by hpa, always clear the attribute space, whether we
are are going to or from 512 chars.

Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty in many
call sites. Only tty_port will needed and hence no more
tty_port_tty_get in those paths.

This is the last one: tty_schedule_flip
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>