\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 81732c3b2f
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: Petr Písař <petr.pisar@atlas.cz>
Cc: stable <stable@vger.kernel.org> # 3.6
Signed-off-by: Greg 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: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg 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: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg 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: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-> The ledptrs[] array is never initialized.
-> There is no place where kbd->ledmode is set to LED_SHOW_MEM therefore the if
statement does not make much sense.
-> Since LED_SHOW_MEM is not used, it can be removed from the header file as well.
Signed-off-by: Andreas Platschek <andi.platschek@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert the tty_buffer_flush() exclusion mechanism to a
public interface - tty_buffer_lock/unlock_exclusive() - and use
the interface to safely write the paste selection to the line
discipline.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Although line discipline receiving is single-producer/single-consumer,
using tty->receive_room to manage flow control creates unnecessary
critical regions requiring additional lock use.
Instead, introduce the optional .receive_buf2() ldisc method which
returns the # of bytes actually received. Serialization is guaranteed
by the caller.
In turn, the line discipline should schedule the buffer work item
whenever space becomes available; ie., when there is room to receive
data and receive_room() previously returned 0 (the buffer work
item stops processing if receive_buf2() returns 0). Note the
'no room' state need not be atomic despite concurrent use by two
threads because only the buffer work thread can set the state and
only the read() thread can clear the state.
Add n_tty_receive_buf2() as the receive_buf2() method for N_TTY.
Provide a public helper function, tty_ldisc_receive_buf(), to use
when directly accessing the receive_buf() methods.
Line disciplines not using input flow control can continue to set
tty->receive_room to a fixed value and only provide the receive_buf()
method.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull second set of VFS changes from Al Viro:
"Assorted f_pos race fixes, making do_splice_direct() safe to call with
i_mutex on parent, O_TMPFILE support, Jeff's locks.c series,
->d_hash/->d_compare calling conventions changes from Linus, misc
stuff all over the place."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (63 commits)
Document ->tmpfile()
ext4: ->tmpfile() support
vfs: export lseek_execute() to modules
lseek_execute() doesn't need an inode passed to it
block_dev: switch to fixed_size_llseek()
cpqphp_sysfs: switch to fixed_size_llseek()
tile-srom: switch to fixed_size_llseek()
proc_powerpc: switch to fixed_size_llseek()
ubi/cdev: switch to fixed_size_llseek()
pci/proc: switch to fixed_size_llseek()
isapnp: switch to fixed_size_llseek()
lpfc: switch to fixed_size_llseek()
locks: give the blocked_hash its own spinlock
locks: add a new "lm_owner_key" lock operation
locks: turn the blocked_list into a hashtable
locks: convert fl_link to a hlist_node
locks: avoid taking global lock if possible when waking up blocked waiters
locks: protect most of the file_lock handling with i_lock
locks: encapsulate the fl_link list handling
locks: make "added" in __posix_lock_file a bool
...
Commit 421b40a628 ("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 <rosslagerwall@gmail.com>
Tested-by: Mikael Pettersson <mikpe@it.uu.se>
Acked-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg 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 dc9641895a ("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: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg 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: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg 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: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg 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: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg 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: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg 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: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg 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: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg 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: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg 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: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vcs_poll_data_free() calls unregister_vt_notifier(), which calls
atomic_notifier_chain_unregister(), which calls synchronize_rcu().
Do it *after* we'd dropped ->f_lock.
Cc: stable@vger.kernel.org (all kernels since 2.6.37)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
