1. 05 8月, 2013 1 次提交
    • C
      vt: make the default color configurable · 3855ae1c
      Clemens Ladisch 提交于
      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>
      3855ae1c
  2. 24 7月, 2013 1 次提交
  3. 21 5月, 2013 9 次提交
    • W
      TTY:vt: convert remain take_over_console's users to do_take_over_console · 155957f5
      Wang YanQing 提交于
      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>
      155957f5
    • W
      vt: delete unneeded function unregister_con_driver · 50539dd4
      Wang YanQing 提交于
      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>
      50539dd4
    • W
      fbcon: convert last two unregister_con_driver call to do_unregister_con_driver · 70125e76
      Wang YanQing 提交于
      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>
      70125e76
    • W
      vt: delete unneeded function bind_con_driver · 77d6c984
      Wang YanQing 提交于
      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>
      77d6c984
    • W
      vt: convert last bind_con_driver call to do_bind_con_driver · c62a1e57
      Wang YanQing 提交于
      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>
      c62a1e57
    • W
      vt: delete unneeded function unbind_con_driver · c1f5e38a
      Wang YanQing 提交于
      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>
      c1f5e38a
    • W
      vt: convert last unbind_con_driver call to do_unbind_con_driver · 618f2b90
      Wang YanQing 提交于
      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>
      618f2b90
    • W
      vt: delete unneeded functions register_con_driver|take_over_console · dc964189
      Wang YanQing 提交于
      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>
      dc964189
    • P
      tty/vt: Fix vc_deallocate() lock order · 421b40a6
      Peter Hurley 提交于
      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>
      421b40a6
  4. 25 2月, 2013 1 次提交
    • N
      tty vt: fix character insertion overflow · a883b70d
      Nicolas Pitre 提交于
      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>
      a883b70d
  5. 08 2月, 2013 2 次提交
  6. 07 2月, 2013 1 次提交
    • D
      vgacon/vt: clear buffer attributes when we load a 512 character font (v2) · 2a248307
      Dave Airlie 提交于
      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>
      2a248307
  7. 16 1月, 2013 2 次提交
  8. 22 11月, 2012 1 次提交
  9. 16 11月, 2012 1 次提交
    • J
      TTY: call tty_port_destroy in the rest of drivers · 191c5f10
      Jiri Slaby 提交于
      After commit "TTY: move tty buffers to tty_port", the tty buffers are
      not freed in some drivers. This is because tty_port_destructor is not
      called whenever a tty_port is freed. This was an assumption I counted
      with but was unfortunately untrue. So fix the drivers to fulfil this
      assumption.
      
      To be sure, the TTY buffers (and later some stuff) are gone along with
      the tty_port, we have to call tty_port_destroy at tear-down places.
      This is mostly where the structure containing a tty_port is freed.
      This patch does exactly that -- put tty_port_destroy at those places.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      191c5f10
  10. 12 10月, 2012 1 次提交
    • J
      kdb,vt_console: Fix missed data due to pager overruns · 17b572e8
      Jason Wessel 提交于
      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>
      17b572e8
  11. 11 9月, 2012 1 次提交
    • J
      tty vt: Fix line garbage in virtual console on command line edition · 81732c3b
      Jean-François Moine 提交于
      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>
      81732c3b
  12. 18 7月, 2012 1 次提交
  13. 17 7月, 2012 1 次提交
  14. 14 6月, 2012 2 次提交
  15. 10 4月, 2012 2 次提交
    • M
      tty/vt: handle bad user buffer in {G,P}IO_CMAP ioctl · 871bdea6
      Michael Gehring 提交于
      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>
      871bdea6
    • K
      printk(): add KERN_CONT where needed in hpet and vt code · 5da527aa
      Kay Sievers 提交于
      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>
      5da527aa
  16. 29 3月, 2012 1 次提交
  17. 09 3月, 2012 5 次提交
  18. 24 8月, 2011 1 次提交
  19. 20 4月, 2011 3 次提交
  20. 31 3月, 2011 1 次提交
  21. 02 3月, 2011 1 次提交
  22. 18 2月, 2011 1 次提交
    • J
      tty,vcs removing con_buf/conf_buf_mtx · fcdba07e
      Jiri Olsa 提交于
      seems there's no longer need for using con_buf/conf_buf_mtx
      as vcs_read/vcs_write buffer for user's data.
      
      The do_con_write function, that was the other user of this,
      is currently using its own kmalloc-ed buffer.
      
      Not sure when this got changed, as I was able to find this code
      in 2.6.9, but it's already gone as far as current git history
      goes - 2.6.12-rc2.
      
      AFAICS there's a behaviour change with the current change.
      The lseek is not completely mutually exclusive with the
      vcs_read/vcs_write - the file->f_pos might get updated
      via lseek callback during the vcs_read/vcs_write processing.
      
      I tried to find out if the prefered behaviour is to keep
      this in sync within read/write/lseek functions, but I did
      not find any pattern on different places.
      
      I guess if user end up calling write/lseek from different
      threads she should know what she's doing. If needed we
      could use dedicated fd mutex/buffer.
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fcdba07e