linux-stable.git/drivers/tty/vt/vt.c, branch linux-4.2.y

tty/vt: Fix the memory leak in visual_init

2015-07-23T22:11:08+00:00

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:
    [] kmemleak_alloc+0x4e/0xb0
    [] kmem_cache_alloc_trace+0x1c8/0x240
    [] con_do_clear_unimap.isra.2+0x83/0xe0
    [] con_clear_unimap+0x22/0x40
    [] vt_ioctl+0xeb8/0x1170
    [] tty_ioctl+0x208/0xca0
    [] do_vfs_ioctl+0x2f8/0x510
    [] SyS_ioctl+0x81/0xa0
    [] system_call_fastpath+0x16/0x75
    [] 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:
    [] kmemleak_alloc+0x4e/0xb0
    [] kmem_cache_alloc_trace+0x1c8/0x240
    [] con_insert_unipair+0x86/0x170
    [] con_set_unimap+0x1b7/0x280
    [] vt_ioctl+0xe65/0x1170
    [] tty_ioctl+0x208/0xca0
    [] do_vfs_ioctl+0x2f8/0x510
    [] SyS_ioctl+0x81/0xa0
    [] system_call_fastpath+0x16/0x75
    [] 0xffffffffffffffff

Signed-off-by: Dongxing Zhang 
Signed-off-by: Xiaoming Wang 
Reviewed-by: Peter Hurley 
Tested-by: Konstantin Khlebnikov 
Signed-off-by: Greg Kroah-Hartman

vt: Don't check KD_GRAPHICS when binding/unbinding

2015-05-10T17:29:51+00:00

This was introduced in

commit 6db4063c5b72b46e9793b0f141a7a3984ac6facf
Author: Antonino A. Daplas 
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 
Cc: Peter Hurley 
Cc: Imre Deak 
Signed-off-by: Daniel Vetter 
Acked-by: David Herrmann 
Signed-off-by: Greg Kroah-Hartman

vt: fix console lock vs. kernfs s_active lock order

2015-05-10T17:29:51+00:00

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: Imre Deak 
Reviewed-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

vt: add cursor blink interval escape sequence

2015-05-10T17:15:52+00:00

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: Scot Doyle 
Acked-by: Pavel Machek 
Signed-off-by: Greg Kroah-Hartman

tty: Use static attribute groups for sysfs entries

2015-03-26T15:10:10+00:00

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: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

vt: use msecs_to_jiffies for time conversion

2015-03-07T03:02:26+00:00

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 
Reviewed-by: David Herrmann 
Signed-off-by: Greg Kroah-Hartman

tty: vt/vt: fix sparse warning

2015-03-07T03:02:26+00:00

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: Lad, Prabhakar 
Signed-off-by: Greg Kroah-Hartman

vt: provide notifications on selection changes

2015-02-02T18:09:54+00:00

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: Nicolas Pitre 
Cc: Dave Mielke 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

vt: fix locking around vt_bind/vt_unbind

2015-01-09T22:39:52+00:00

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: Imre Deak 
Reviewed-by: Peter Hurley 
Reviewed-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

vt: fix check for system/busy console drivers when unregistering them

2015-01-09T22:39:52+00:00

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: Imre Deak 
Reviewed-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman