linux-toradex.git/include/linux/vt_kern.h, branch v4.6-rc6

Merge 3.10-rc3 into tty-next

2013-05-27T01:57:53+00:00

We want these fixes.

Signed-off-by: Greg Kroah-Hartman

vt: delete unneeded function unbind_con_driver

2013-05-20T19:27:59+00:00

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

tty/vt: Fix vc_deallocate() lock order

2013-05-20T19:15:59+00:00

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

Merge branch 'console-fixes' into drm-next

2013-02-08T02:13:43+00:00

(not the fbcon maintainer pull 2)

fix bug in vgacon on bootup and fbcon losing fonts on startup.

* console-fixes: (50 commits)
  fbcon: don't lose the console font across generic->chip driver switch
  vgacon/vt: clear buffer attributes when we load a 512 character font (v2)

fb: Yet another band-aid for fixing lockdep mess

2013-02-08T02:02:41+00:00

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: Takashi Iwai 
Cc: Alan Cox 
Cc: Florian Tobias Schandinat 
Cc: Jiri Kosina 
Cc: stable 
Tested-by: Sedat Dilek 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Airlie

vgacon/vt: clear buffer attributes when we load a 512 character font (v2)

2013-02-07T02:37:03+00:00

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: Dave Airlie

vt: push the tty_lock down into the map handling

2012-04-24T23:14:14+00:00

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:tackle kbd_table

2012-03-08T18:50:35+00:00

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

vt: lock the accent table

2012-02-24T21:59:34+00:00

First step to debletcherising the vt console layer - pick a victim and fix
the locking

This is a nice simple object with its own rules so lets pick it out for
treatment. The user of the table already has a lock so we will also use the
same lock for updates.

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

panic, vt: do not force oops output when panic_timeout < 0

2011-07-26T23:49:45+00:00

Don't force output if you intend to reboot immediately.

In this patch, I'm disabling the functionality enabled by
vc->vc_panic_force_write if panic_timeout < 0 (i.e.  no timeout).
vc_panic_force_write is only enabled for fb video consoles if the
FBINFO_CAN_FORCE_OUTPUT flag is set.

For our application, we're using ram_oops to preserved the panic in
memory.  We want to reliably, and as fast as possible, machine_restart.
The vc_panic_force_write flag results in a bunch of graphics driver code
to be invoked which slows down restart and decreases reliability.  Since
we're already storing the panic in RAM and are going to reboot
immediately, there is no benefit in mode switching back to the vc in
order to display the panic output.  The log buffer will get flushed by
the console_unblank() call so remote management consoles should see all
output.

Signed-off-by: Mandeep Singh Baines 
Cc: Huang Ying 
Cc: Andi Kleen 
Cc: Hugh Dickins 
Cc: Olaf Hering 
Cc: Jesse Barnes 
Cc: Dave Airlie 
Cc: Greg Kroah-Hartman 
Acked-by: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds