1. 31 Mar, 2017 1 commit
  2. 02 Mar, 2017 1 commit
  3. 25 Jan, 2017 1 commit
  4. 27 Oct, 2016 8 commits
  5. 09 Oct, 2016 1 commit
    • Linus Torvalds's avatar
      printk: reinstate KERN_CONT for printing continuation lines · 4bcc595c
      Linus Torvalds authored
      Long long ago the kernel log buffer was a buffered stream of bytes, very
      much like stdio in user space.  It supported log levels by scanning the
      stream and noticing the log level markers at the beginning of each line,
      but if you wanted to print a partial line in multiple chunks, you just
      did multiple printk() calls, and it just automatically worked.
      Except when it didn't, and you had very confusing output when different
      lines got all mixed up with each other.  Then you got fragment lines
      mixing with each other, or with non-fragment lines, because it was
      traditionally impossible to tell whether a printk() call was a
      continuation or not.
      To at least help clarify the issue of continuation lines, we added a
      KERN_CONT marker back in 2007 to mark continuation lines:
        47492527 ("printk: add KERN_CONT annotation").
      That continuation marker was initially an empty string, and didn't
      actuall make any semantic difference.  But it at least made it possible
      to annotate the source code, and have check-patch notice that a printk()
      didn't need or want a log level marker, because it was a continuation of
      a previous line.
      To avoid the ambiguity between a continuation line that had that
      KERN_CONT marker, and a printk with no level information at all, we then
      in 2009 made KERN_CONT be a real log level marker which meant that we
      could now reliably tell the difference between the two cases.
        5fd29d6c ("printk: clean up handling of log-levels and newlines")
      and we could take advantage of that to make sure we didn't mix up
      continuation lines with lines that just didn't have any loglevel at all.
      Then, in 2012, the kernel log buffer was changed to be a "record" based
      log, where each line was a record that has a loglevel and a timestamp.
      You can see the beginning of that conversion in commits
        e11fea92 ("kmsg: export printk records to the /dev/kmsg interface")
        7ff9554b ("printk: convert byte-buffer to variable-length record buffer")
      with a number of follow-up commits to fix some painful fallout from that
      conversion.  Over all, it took a couple of months to sort out most of
      it.  But the upside was that you could have concurrent readers (and
      writers) of the kernel log and not have lines with mixed output in them.
      And one particular pain-point for the record-based kernel logging was
      exactly the fragmentary lines that are generated in smaller chunks.  In
      order to still log them as one recrod, the continuation lines need to be
      attached to the previous record properly.
      However the explicit continuation record marker that is actually useful
      for this exact case was actually removed in aroundm the same time by commit
       ("printk: remove the now unnecessary "C" annotation for KERN_CONT")
      due to the incorrect belief that KERN_CONT wasn't meaningful.  The
      ambiguity between "is this a continuation line" or "is this a plain
      printk with no log level information" was reintroduced, and in fact
      became an even bigger pain point because there was now the whole
      record-level merging of kernel messages going on.
      This patch reinstates the KERN_CONT as a real non-empty string marker,
      so that the ambiguity is fixed once again.
      But it's not a plain revert of that original removal: in the four years
      since we made KERN_CONT an empty string again, not only has the format
      of the log level markers changed, we've also had some usage changes in
      this area.
      For example, some ACPI code seems to use KERN_CONT _together_ with a log
      level, and now uses both the KERN_CONT marker and (for example) a
      KERN_INFO marker to show that it's an informational continuation of a
      Which is actually not a bad idea - if the continuation line cannot be
      attached to its predecessor, without the log level information we don't
      know what log level to assign to it (and we traditionally just assigned
      it the default loglevel).  So having both a log level and the KERN_CONT
      marker is not necessarily a bad idea, but it does mean that we need to
      actually iterate over potentially multiple markers, rather than just a
      single one.
      Also, since KERN_CONT was still conceptually needed, and encouraged, but
      didn't actually _do_ anything, we've also had the reverse problem:
      rather than having too many annotations it has too few, and there is bit
      rot with code that no longer marks the continuation lines with the
      KERN_CONT marker.
      So this patch not only re-instates the non-empty KERN_CONT marker, it
      also fixes up the cases of bit-rot I noticed in my own logs.
      There are probably other cases where KERN_CONT will be needed to be
      added, either because it is new code that never dealt with the need for
      KERN_CONT, or old code that has bitrotted without anybody noticing.
      That said, we should strive to avoid the need for KERN_CONT.  It does
      result in real problems for logging, and should generally not be seen as
      a good feature.  If we some day can get rid of the feature entirely,
      because nobody does any fragmented printk calls, that would be lovely.
      But until that point, let's at mark the code that relies on the hacky
      multi-fragment kernel printk's.  Not only does it avoid the ambiguity,
      it also annotates code as "maybe this would be good to fix some day".
      (That said, particularly during single-threaded bootup, the downsides of
      KERN_CONT are very limited.  Things get much hairier when you have
      multiple threads going on and user level reading and writing logs too).
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  6. 22 Sep, 2016 5 commits
  7. 17 Sep, 2016 1 commit
  8. 25 Jun, 2016 12 commits
  9. 03 May, 2016 2 commits
  10. 30 Apr, 2016 4 commits
  11. 07 Feb, 2016 1 commit
    • Melchior FRANZ's avatar
      tty: vt: initialize softcursor_original correctly · e882f715
      Melchior FRANZ authored
      add_softcursor() stores the contents of the text buffer position in this
      variable before drawing the softcursor, whereas hide_softcursor() writes
      the value back. A value of -1 means that no cursor has been drawn and
      therefore no character is to be restored. softcursor_original, however,
      is only implicitly initialized with 0. Therefore, when hide_softcursor
      is called for the first time (console_init -> con_init -> redraw_screen
      -> hide_cursor), it wrongly writes 0x0000 in the top left corner of
      the text buffer. Normally, this is just as black as the rest of the
      screen (vc_video_erase_char) and can't be seen, but it appears as a
      black cursor rectangle on non-black backgrounds e.g. with boot option
      "vt.global_cursor_default=0 vt.color=0xf0". softcursor_original needs
      to be initialized with -1.
      Signed-off-by: default avatarMelchior FRANZ <mfranz@aon.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. 29 Jan, 2016 1 commit
  13. 14 Dec, 2015 1 commit
  14. 23 Jul, 2015 1 commit
    • Dongxing Zhang's avatar
      tty/vt: Fix the memory leak in visual_init · 08b33249
      Dongxing Zhang authored
      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+....
          [<ffffffff817b755e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811d4898>] kmem_cache_alloc_trace+0x1c8/0x240
          [<ffffffff814ae7d3>] con_do_clear_unimap.isra.2+0x83/0xe0
          [<ffffffff814ae9b2>] con_clear_unimap+0x22/0x40
          [<ffffffff814a8db8>] vt_ioctl+0xeb8/0x1170
          [<ffffffff8149b458>] tty_ioctl+0x208/0xca0
          [<ffffffff81207858>] do_vfs_ioctl+0x2f8/0x510
          [<ffffffff81207af1>] SyS_ioctl+0x81/0xa0
          [<ffffffff817ca2b2>] system_call_fastpath+0x16/0x75
          [<ffffffffffffffff>] 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  ................
          [<ffffffff817b755e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811d4898>] kmem_cache_alloc_trace+0x1c8/0x240
          [<ffffffff814ae286>] con_insert_unipair+0x86/0x170
          [<ffffffff814af107>] con_set_unimap+0x1b7/0x280
          [<ffffffff814a8d65>] vt_ioctl+0xe65/0x1170
          [<ffffffff8149b458>] tty_ioctl+0x208/0xca0
          [<ffffffff81207858>] do_vfs_ioctl+0x2f8/0x510
          [<ffffffff81207af1>] SyS_ioctl+0x81/0xa0
          [<ffffffff817ca2b2>] system_call_fastpath+0x16/0x75
          [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: default avatarDongxing Zhang <dongxing.zhang@intel.com>
      Signed-off-by: default avatarXiaoming Wang <xiaoming.wang@intel.com>
      Reviewed-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Tested-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>