1. 07 11月, 2019 1 次提交
  2. 18 10月, 2019 30 次提交
  3. 17 10月, 2019 1 次提交
    • R
      printf: add support for printing symbolic error names · 57f5677e
      Rasmus Villemoes 提交于
      It has been suggested several times to extend vsnprintf() to be able
      to convert the numeric value of ENOSPC to print "ENOSPC". This
      implements that as a %p extension: With %pe, one can do
      
        if (IS_ERR(foo)) {
          pr_err("Sorry, can't do that: %pe\n", foo);
          return PTR_ERR(foo);
        }
      
      instead of what is seen in quite a few places in the kernel:
      
        if (IS_ERR(foo)) {
          pr_err("Sorry, can't do that: %ld\n", PTR_ERR(foo));
          return PTR_ERR(foo);
        }
      
      If the value passed to %pe is an ERR_PTR, but the library function
      errname() added here doesn't know about the value, the value is simply
      printed in decimal. If the value passed to %pe is not an ERR_PTR, we
      treat it as an ordinary %p and thus print the hashed value (passing
      non-ERR_PTR values to %pe indicates a bug in the caller, but we can't
      do much about that).
      
      With my embedded hat on, and because it's not very invasive to do,
      I've made it possible to remove this. The errname() function and
      associated lookup tables take up about 3K. For most, that's probably
      quite acceptable and a price worth paying for more readable
      dmesg (once this starts getting used), while for those that disable
      printk() it's of very little use - I don't see a
      procfs/sysfs/seq_printf() file reasonably making use of this - and
      they clearly want to squeeze vmlinux as much as possible. Hence the
      default y if PRINTK.
      
      The symbols to include have been found by massaging the output of
      
        find arch include -iname 'errno*.h' | xargs grep -E 'define\s*E'
      
      In the cases where some common aliasing exists
      (e.g. EAGAIN=EWOULDBLOCK on all platforms, EDEADLOCK=EDEADLK on most),
      I've moved the more popular one (in terms of 'git grep -w Efoo | wc)
      to the bottom so that one takes precedence.
      
      Link: http://lkml.kernel.org/r/20191015190706.15989-1-linux@rasmusvillemoes.dk
      To: "Jonathan Corbet" <corbet@lwn.net>
      To: linux-kernel@vger.kernel.org
      Cc: "Andy Shevchenko" <andy.shevchenko@gmail.com>
      Cc: "Andrew Morton" <akpm@linux-foundation.org>
      Cc: "Joe Perches" <joe@perches.com>
      Cc: linux-doc@vger.kernel.org
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Acked-by: NUwe Kleine-König <uwe@kleine-koenig.org>
      Reviewed-by: NPetr Mladek <pmladek@suse.com>
      [andy.shevchenko@gmail.com: use abs()]
      Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      57f5677e
  4. 16 9月, 2019 1 次提交
  5. 06 9月, 2019 1 次提交
  6. 16 8月, 2019 1 次提交
  7. 15 8月, 2019 3 次提交
  8. 12 7月, 2019 1 次提交
    • V
      printk: Do not lose last line in kmsg buffer dump · c9dccacf
      Vincent Whitchurch 提交于
      kmsg_dump_get_buffer() is supposed to select all the youngest log
      messages which fit into the provided buffer.  It determines the correct
      start index by using msg_print_text() with a NULL buffer to calculate
      the size of each entry.  However, when performing the actual writes,
      msg_print_text() only writes the entry to the buffer if the written len
      is lesser than the size of the buffer.  So if the lengths of the
      selected youngest log messages happen to precisely fill up the provided
      buffer, the last log message is not included.
      
      We don't want to modify msg_print_text() to fill up the buffer and start
      returning a length which is equal to the size of the buffer, since
      callers of its other users, such as kmsg_dump_get_line(), depend upon
      the current behaviour.
      
      Instead, fix kmsg_dump_get_buffer() to compensate for this.
      
      For example, with the following two final prints:
      
      [    6.427502] AAAAAAAAAAAAA
      [    6.427769] BBBBBBBB12345
      
      A dump of a 64-byte buffer filled by kmsg_dump_get_buffer(), before this
      patch:
      
       00000000: 3c 30 3e 5b 20 20 20 20 36 2e 35 32 32 31 39 37  <0>[    6.522197
       00000010: 5d 20 41 41 41 41 41 41 41 41 41 41 41 41 41 0a  ] AAAAAAAAAAAAA.
       00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      
      After this patch:
      
       00000000: 3c 30 3e 5b 20 20 20 20 36 2e 34 35 36 36 37 38  <0>[    6.456678
       00000010: 5d 20 42 42 42 42 42 42 42 42 31 32 33 34 35 0a  ] BBBBBBBB12345.
       00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      
      Link: http://lkml.kernel.org/r/20190711142937.4083-1-vincent.whitchurch@axis.com
      Fixes: e2ae715d ("kmsg - kmsg_dump() use iterator to receive log buffer content")
      To: rostedt@goodmis.org
      Cc: linux-kernel@vger.kernel.org
      Cc: <stable@vger.kernel.org> # v3.5+
      Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
      Reviewed-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      c9dccacf
  9. 10 7月, 2019 1 次提交