There used to be a single tty_ldisc_ref_wait. But then, when a
big-tty-mutex (BTM) was introduced, it has to be tty_ldisc_ref +
tty_unlock + tty_ldisc_ref_wait + tty_lock. Later, BTM was removed
from that path and tty_ldisc_ref + tty_ldisc_ref_wait remained there.
But it makes no sense now. So leave there only tty_ldisc_ref_wait.

And when we have a reference to an ldisc, actually use it in the loop.
Otherwise it may be racy.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is possible to miss data when using the kdb pager.  The kdb pager
does not pay attention to the maximum column constraint of the screen
or serial terminal.  This result is not incrementing the shown lines
correctly and the pager will print more lines that fit on the screen.
Obviously that is less than useful when using a VGA console where you
cannot scroll back.

The pager will now look at the kdb_buffer string to see how many
characters are printed.  It might not be perfect considering you can
output ASCII that might move the cursor position, but it is a
substantially better approximation for viewing dmesg and trace logs.

This also means that the vt screen needs to set the kdb COLUMNS
variable.

Cc: <stable@vger.kernel.org>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

On some machines using a specific hardware for console screen output,
the update of the pixel frame buffer does not work correctly when
using command line edition. This may be due to a memory cache bug
in the machine on which the problem has been found, but an other
solution is possible.

This patch proposes to avoid touching directly the pixel frame buffer
and to rebuild each character using the standard putc() function
on command line edition.

The resulting code is smaller and not obviously slower (no read
access to the pixel frame buffer).

Tested on a Cubox (ARM Marvell Dove 88AP510 SoC).
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NRabin Vincent <rabin.vincent@stericsson.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that we don't have tty->termios tied to drivers->tty we can untangle
the logic here. In addition we can push the removal logic out of the
destructor path.

At that point we can think about sorting out tty_port and console and all
the other ugly hangovers.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We touch the LED from both keyboard callback and direct paths. In
one case we've got the lock held way up the call chain and in the
other we haven't. This leads to complete insanity so fix it by giving
the LED bits their own lock.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This will let us sort out a whole pile of tty related races. The
alternative would be to keep points and refcount the termios objects.
However
1. They are tiny anyway
2. Many devices don't use the stored copies
3. We can remove a pty special case
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are three call sites for this function, and all three
are called within a keyboard handler.
kbd_event_lock is already held within keyboard handlers,
so attempting to lock it in vt_get_leds causes deadlock.
Signed-off-by: NChristopher Brannon <chris@the-brannons.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NRabin Vincent <rabin.vincent@stericsson.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We need to initialize the console only on the first open. This is
usually what is done in the ->install hook. vt used to do this in
->open. Now we move it to ->install and use newly added helper for
install: tty_port_install. It ensures tty->port to be set properly.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is identical to tty_schedule_flip. So let us use that instead.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

3.4-rc introduced a regression when setting the LEDS. We do the right thing
but then return an error code.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=43144
Reported-by: Christian Casteyde
Signed-off-by: NAlan Cox <alan@linux/intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

3.4-rc introduced a regression when setting the LEDS. We do the right thing
but then return an error code.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=43144
Reported-by: Christian Casteyde
Signed-off-by: NAlan Cox <alan@linux/intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The PC BIOS does provide a NUMLOCK flag containing the desired state
of this LED. This patch sets the current state according to the data
in the bios.

[ hpa: fixed __weak declaration without definition, changed "inline"
  to "static inline" ]
Signed-Off-By: NJoshua Cov <joshuacov@googlemail.com>
Link: http://lkml.kernel.org/r/CAKL7Q7rvq87TNS1T_Km8fW_5OzS%2BSbYazLXKxW-6ztOxo3zorg@mail.gmail.comAcked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Fixing the locking accidentally replaced a race in the scroll
lock handling with a deadlock. Turn it back into a race for
now.

The basic problem is that there are two paths into the tty
stop/start helpers. One via the tty layer ^S/^Q handling
where we need to take the kbd_event_lock and one via the
special keyboard handler for fn_hold where we already hold
it. Probably we need to split out into a separate LED lock
but for now just go back to the race as it's a bit close
to release.
Reported-by: NClemens Ladisch <clemens@ladisch.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

set_get_cmap() ignored the result of {get,put}_user(), causing ioctl(vt,
{G,P}IO_CMAP, 0xdeadbeef) to silently fail.

Another side effect of this: calling the PIO_CMAP ioctl with an invalid
buffer would zero the default colormap and the palette for all vts (all
colors set to black).

Leave the default colormap intact and return -EFAULT when
reading/writing to the userspace buffer fails.
Signed-off-by: NMichael Gehring <mg@ebfe.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A prototype for kmsg records instead of a byte-stream buffer revealed
a couple of missing printk(KERN_CONT ...) uses. Subsequent calls produce
one record per printk() call, while all should have ended up in a single
record.

Instead of:
  ACPI: (supports S0 S5)
  ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
  hpet0: at MMIO 0xfed00000, IRQs 2 , 8 , 0

It prints:
  ACPI: (supports S0
   S5
  )
  ACPI: PCI Interrupt Link [LNKA] (IRQs
   5
   *10
   11
  )
  hpet0: at MMIO 0xfed00000, IRQs
   2
  , 8
  , 0

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NKay Sievers <kay@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove all #inclusions of asm/system.h preparatory to splitting and killing
it.  Performed with the following command:

perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`
Signed-off-by: NDavid Howells <dhowells@redhat.com>

Bugzilla 40012: PIO_UNIMAP bug: error updating Unicode-to-font map
https://bugzilla.kernel.org/show_bug.cgi?id=40012

The unicode font map for the virtual console is a 32x32x64 table which
allocates rows dynamically as entries are added.  The unicode value
increases sequentially and should count all entries even in empty
rows.  The defect is when copying the unicode font map in con_set_unimap(),
the unicode value is not incremented properly.  The wrong unicode value
is entered in the new font map.
Signed-off-by: NLiz Clark <liz.clark@hp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We forgot to set the "key_map" variable here, so it's still NULL.  This
was introduced recently in 079c9534 "vt:tackle kbd_table".
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All num, magic and owner are set by alloc_tty_driver. No need to
re-set them on each allocation site.

pti driver sets something different to what it passes to
alloc_tty_driver. It is not a bug, since we don't use the lines
parameter in any way. Anyway this is fixed, and now we do the right
thing.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NTilman Schmidt <tilman@imap.cc>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We leave the existing paste mess alone and just fix up the vt side of
things.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The font methods are console_lock covered. Unfortunately they don't extend
the lock over all the needed tests.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland
with a 64bit kernel if the font width is not 8.

This is because of the setting of the KD_FONT_FLAG_OLD flag, which makes
con_font_get return EIO in such case.

This flag should *not* be set for KDFONTOP, since it's actually the whole
point of this flag (see comment in con_font_set for instance).
Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Arthur Taylor <art@ified.ca>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland
with a 64bit kernel if the font width is not 8.

This is because the compatibility layer introduced by e9216651 ("tty:
handle VT specific compat ioctls in vt driver") forces the addition of the
KD_FONT_FLAG_OLD flag, which makes con_font_get return EIO in such case.

This flag should *not* be set for KDFONTOP, since it's actually the whole
point of this flag (see comment in con_font_set for instance).
Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Arthur Taylor <art@ified.ca>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Virtual console unicode translation map leaks with following
message when enable kmemleak:

unreferenced object 0xeb5ec450 (size 192):
  comm "setfont", pid 665, jiffies 4294899028 (age 3696.220s)
  hex dump (first 32 bytes):
    e0 5b 9d eb 00 00 00 00 00 00 00 00 80 b9 ea eb  .[..............
    b0 5a 9d eb 00 00 00 00 00 00 00 00 00 00 00 00  .Z..............
  backtrace:
    [<c1533f8c>] kmemleak_alloc+0x3c/0xa0
    [<c114acc2>] kmem_cache_alloc_trace+0xe2/0x250
    [<c13498e8>] con_clear_unimap+0x78/0xd0
    [<c1345552>] vt_ioctl+0x1562/0x1d00
    [<c133aa00>] tty_ioctl+0x230/0x7c0
    [<c1171519>] do_vfs_ioctl+0x79/0x2d0
    [<c11717df>] sys_ioctl+0x6f/0x80
    [<c156601f>] sysenter_do_call+0x12/0x38
    [<ffffffff>] 0xffffffff
unreferenced object 0xeb9d5be0 (size 128):
  comm "setfont", pid 660, jiffies 4294899030 (age 3696.212s)
  hex dump (first 32 bytes):
    60 c2 a6 eb 50 c8 a6 eb c0 54 9d eb 80 59 9d eb  `...P....T...Y..
    90 53 9d eb 60 52 9d eb 60 92 9b eb 00 00 00 00  .S..`R..`.......
  backtrace:
    [<c1533f8c>] kmemleak_alloc+0x3c/0xa0
    [<c114acc2>] kmem_cache_alloc_trace+0xe2/0x250
    [<c134938c>] con_insert_unipair+0x7c/0x150
    [<c1349f8c>] con_set_unimap+0x15c/0x1f0
    [<c13456fb>] vt_ioctl+0x170b/0x1d00
    [<c133aa00>] tty_ioctl+0x230/0x7c0
    [<c1171519>] do_vfs_ioctl+0x79/0x2d0
    [<c11717df>] sys_ioctl+0x6f/0x80
    [<c156601f>] sysenter_do_call+0x12/0x38
    [<ffffffff>] 0xffffffff

The leak caused by con_set_default_unimap() not correct free the old map.
Signed-off-by: NZeng Zhaoming <zengzm.kernel@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

With module.h being implicitly everywhere via device.h, the absence
of explicitly including something for EXPORT_SYMBOL went unnoticed.
Since we are heading to fix things up and clean module.h from the
device.h file, we need to explicitly include these files now.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

The top of <linux/irq.h> has this comment:

 * Please do not include this file in generic code.  There is currently
 * no requirement for any architecture to implement anything held
 * within this file.
 *
 * Thanks. --rmk

Remove inclusion of <linux/irq.>, to prevent the following compile error
from happening soon:

| include/linux/irq.h:132: error: redefinition of ‘struct irq_data’
| include/linux/irq.h:286: error: redefinition of ‘struct irq_chip’

drivers/tty/vt/keyboard.c needs to include <asm/irq_regs.h> for get_irq_regs():

| drivers/tty/vt/keyboard.c:497: error: implicit declaration of function ‘get_irq_regs’
| drivers/tty/vt/keyboard.c:497: warning: initialization makes pointer from integer without a cast
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Even though this is valid C we should not mix C99 initializers with
obfuscated ANSI C. Stick to C99 and initialize c by its name.

Found by clang:
drivers/tty/vt/vt.c:262:55: warning: explicitly assigning a variable of
type 'unsigned int' to itself [-Wself-assign]
    struct vt_notifier_param param = { .vc = vc, unicode = unicode };
                                                 ~~~~~~~ ^ ~~~~~~~
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We used it really only serial and ami_serial. The rest of the
callsites were BUG/WARN_ONs to check if BTM is held. Now that we
pruned tty_locked from both of the real users, we can get rid of
tty_lock along with __big_tty_mutex_owner.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit b1c43f82.

It was broken in so many ways, and results in random odd pty issues.

It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
cause endless work-loops (see commit a5660b41: "tty: fix endless
work loop when the buffer fills up").

It also used an "unsigned int" return value fo the ->receive_buf()
function, but then made multiple functions return a negative error code,
and didn't actually check for the error in the caller.

And it didn't actually work at all.  BenH bisected down odd tty behavior
to it:
  "It looks like the patch is causing some major malfunctions of the X
   server for me, possibly related to PTYs.  For example, cat'ing a
   large file in a gnome terminal hangs the kernel for -minutes- in a
   loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
   data in the quoted bits further down).

   ...

   Some more data: It -looks- like what happens is that the
   flush_to_ldisc work queue entry constantly re-queues itself (because
   the PTY is full ?) and the workqueue thread will basically loop
   forver calling it without ever scheduling, thus starving the consumer
   process that could have emptied the PTY."

which is pretty much exactly the problem we fixed in a5660b41.

Milton Miller pointed out the 'unsigned int' issue.
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: NMilton Miller <miltonm@bga.com>
Cc: Stefan Bigler <stefan.bigler@keymile.com>
Cc: Toby Gray <toby.gray@realvnc.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

it makes it simpler to keep track of the amount of
bytes received and simplifies how flush_to_ldisc counts
the remaining bytes. It also fixes a bug of lost bytes
on n_tty when flushing too many bytes via the USB
serial gadget driver.
Tested-by: NStefan Bigler <stefan.bigler@keymile.com>
Tested-by: NToby Gray <toby.gray@realvnc.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>