1. 03 Jul, 2018 1 commit
    • Geert Uytterhoeven's avatar
      lib/vsprintf: Remove atomic-unsafe support for %pCr · ea0ac01f
      Geert Uytterhoeven authored
      commit 666902e4 upstream.
      
      "%pCr" formats the current rate of a clock, and calls clk_get_rate().
      The latter obtains a mutex, hence it must not be called from atomic
      context.
      
      Remove support for this rarely-used format, as vsprintf() (and e.g.
      printk()) must be callable from any context.
      
      Any remaining out-of-tree users will start seeing the clock's name
      printed instead of its rate.
      Reported-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Fixes: 900cca29 ("lib/vsprintf: add %pC{,n,r} format specifiers for clocks")
      Link: http://lkml.kernel.org/r/1527845302-12159-5-git-send-email-geert+renesas@glider.be
      To: Jia-Ju Bai <baijiaju1990@gmail.com>
      To: Jonathan Corbet <corbet@lwn.net>
      To: Michael Turquette <mturquette@baylibre.com>
      To: Stephen Boyd <sboyd@kernel.org>
      To: Zhang Rui <rui.zhang@intel.com>
      To: Eduardo Valentin <edubezval@gmail.com>
      To: Eric Anholt <eric@anholt.net>
      To: Stefan Wahren <stefan.wahren@i2se.com>
      To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linux-doc@vger.kernel.org
      Cc: linux-clk@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Cc: linux-serial@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-renesas-soc@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea0ac01f
  2. 27 Jun, 2017 1 commit
    • Pantelis Antoniou's avatar
      vsprintf: Add %p extension "%pOF" for device tree · ce4fecf1
      Pantelis Antoniou authored
      90% of the usage of device node's full_name is printing it out in a
      kernel message. However, storing the full path for every node is
      wasteful and redundant. With a custom format specifier, we can generate
      the full path at run-time and eventually remove the full path from every
      node.
      
      For instance typical use is:
      	pr_info("Frobbing node %s\n", node->full_name);
      
      Which can be written now as:
      	pr_info("Frobbing node %pOF\n", node);
      
      '%pO' is the base specifier to represent kobjects with '%pOF'
      representing struct device_node. Currently, struct device_node is the
      only supported type of kobject.
      
      More fine-grained control of formatting includes printing the name,
      flags, path-spec name and others, explained in the documentation entry.
      
      Originally written by Pantelis, but pretty much rewrote the core
      function using existing string/number functions. The 2 passes were
      unnecessary and have been removed. Also, updated the checkpatch.pl
      check. The unittest code was written by Grant Likely.
      Signed-off-by: default avatarPantelis Antoniou <pantelis.antoniou@konsulko.com>
      Acked-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      ce4fecf1
  3. 05 Jun, 2017 1 commit
  4. 09 May, 2017 1 commit
  5. 02 Apr, 2017 1 commit
  6. 28 Feb, 2017 1 commit
  7. 21 May, 2016 2 commits
    • Andy Shevchenko's avatar
      lib/uuid.c: introduce a few more generic helpers · 2b1b0d66
      Andy Shevchenko authored
      There are new helpers in this patch:
      
        uuid_is_valid		checks if a UUID is valid
        uuid_be_to_bin	converts from string to binary (big endian)
        uuid_le_to_bin	converts from string to binary (little endian)
      
      They will be used in future, i.e. in the following patches in the series.
      
      This also moves the indices arrays to lib/uuid.c to be shared accross
      modules.
      
      [andriy.shevchenko@linux.intel.com: fix typo]
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
      Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2b1b0d66
    • Andy Shevchenko's avatar
      lib/vsprintf: simplify UUID printing · aa4ea1c3
      Andy Shevchenko authored
      There are few functions here and there along with type definitions that
      provide UUID API.  This series consolidates everything under one hood
      and converts current users.
      
      This has been tested for a while internally, however it doesn't mean we
      covered all possible cases (especially accuracy of UUID constants after
      conversion).  So, please test this as much as you can and provide your
      tag.  We appreciate the effort.
      
      The ACPI conversion is postponed for now to sort more generic things out
      first.
      
      This patch (of 9):
      
      Since we have hex_byte_pack_upper() we may use it directly and avoid
      second loop.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
      Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      aa4ea1c3
  8. 17 Mar, 2016 1 commit
    • Jessica Yu's avatar
      sscanf: implement basic character sets · f9310b2f
      Jessica Yu authored
      Implement basic character sets for the '%[' conversion specifier.
      
      The '%[' conversion specifier matches a nonempty sequence of characters
      from the specified set of accepted (or with '^', rejected) characters
      between the brackets.  The substring matched is to be made up of
      characters in (or not in) the set.  This is useful for matching
      substrings that are delimited by something other than spaces.
      
      This implementation differs from its glibc counterpart in the following ways:
       (1) No support for character ranges (e.g., 'a-z' or '0-9')
       (2) The hyphen '-' is not a special character
       (3) The closing bracket ']' cannot be matched
       (4) No support (yet) for discarding matching input ('%*[')
      
      The bitmap code is largely based upon sample code which was provided by
      Rasmus.
      
      The motivation for adding character set support to sscanf originally
      stemmed from the kernel livepatching project.  An ongoing patchset
      utilizes new livepatch Elf symbol and section names to store important
      metadata livepatch needs to properly apply its patches.  Such metadata
      is stored in these section and symbol names as substrings delimited by
      periods '.' and commas ','.  For example, a livepatch symbol name might
      look like this:
      
      .klp.sym.vmlinux.printk,0
      
      However, sscanf currently can only extract "substrings" delimited by
      whitespace using the "%s" specifier.  Thus for the above symbol name,
      one cannot not use sscanf() to extract substrings "vmlinux" or
      "printk", for example.  A number of discussions on the livepatch
      mailing list dealing with string parsing code for extracting these '.'
      and ',' delimited substrings eventually led to the conclusion that such
      code would be completely unnecessary if the kernel sscanf() supported
      character sets.  Thus only a single sscanf() call would be necessary to
      extract these substrings.  In addition, such an addition to sscanf()
      could benefit other areas of the kernel that might have a similar need
      in the future.
      
      [akpm@linux-foundation.org: 80-col tweaks]
      Signed-off-by: default avatarJessica Yu <jeyu@redhat.com>
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f9310b2f
  9. 15 Mar, 2016 1 commit
    • Vlastimil Babka's avatar
      mm, printk: introduce new format string for flags · edf14cdb
      Vlastimil Babka authored
      In mm we use several kinds of flags bitfields that are sometimes printed
      for debugging purposes, or exported to userspace via sysfs.  To make
      them easier to interpret independently on kernel version and config, we
      want to dump also the symbolic flag names.  So far this has been done
      with repeated calls to pr_cont(), which is unreliable on SMP, and not
      usable for e.g.  sysfs export.
      
      To get a more reliable and universal solution, this patch extends
      printk() format string for pointers to handle the page flags (%pGp),
      gfp_flags (%pGg) and vma flags (%pGv).  Existing users of
      dump_flag_names() are converted and simplified.
      
      It would be possible to pass flags by value instead of pointer, but the
      %p format string for pointers already has extensions for various kernel
      structures, so it's a good fit, and the extra indirection in a
      non-critical path is negligible.
      
      [linux@rasmusvillemoes.dk: lots of good implementation suggestions]
      Signed-off-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      edf14cdb
  10. 12 Feb, 2016 1 commit
  11. 16 Jan, 2016 8 commits
  12. 06 Jan, 2016 1 commit
  13. 07 Nov, 2015 5 commits
  14. 20 Jul, 2015 1 commit
  15. 17 Apr, 2015 2 commits
    • Rasmus Villemoes's avatar
      lib/vsprintf.c: improve put_dec_trunc8 slightly · 675cf53c
      Rasmus Villemoes authored
      I hadn't had enough coffee when I wrote this. Currently, the final
      increment of buf depends on the value loaded from the table, and
      causes gcc to emit a cmov immediately before the return. It is smarter
      to let it depend on r, since the increment can then be computed in
      parallel with the final load/store pair. It also shaves 16 bytes of
      .text.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      675cf53c
    • Rasmus Villemoes's avatar
      lib/vsprintf.c: even faster binary to decimal conversion · 7c43d9a3
      Rasmus Villemoes authored
      The most expensive part of decimal conversion is the divisions by 10
      (albeit done using reciprocal multiplication with appropriately chosen
      constants).  I decided to see if one could eliminate around half of
      these multiplications by emitting two digits at a time, at the cost of a
      200 byte lookup table, and it does indeed seem like there is something
      to be gained, especially on 64 bits.  Microbenchmarking shows
      improvements ranging from -50% (for numbers uniformly distributed in [0,
      2^64-1]) to -25% (for numbers heavily biased toward the smaller end, a
      more realistic distribution).
      
      On a larger scale, perf shows that top, one of the big consumers of /proc
      data, uses 0.5-1.0% fewer cpu cycles.
      
      I had to jump through some hoops to get the 32 bit code to compile and run
      on my 64 bit machine, so I'm not sure how relevant these numbers are, but
      just for comparison the microbenchmark showed improvements between -30%
      and -10%.
      
      The bloat-o-meter costs are around 150 bytes (the generated code is a
      little smaller, so it's not the full 200 bytes) on both 32 and 64 bit.
      I'm aware that extra cache misses won't show up in a microbenchmark as
      used above, but on the other hand decimal conversions often happen in bulk
      (for example in the case of top).
      
      I have of course tested that the new code generates the same output as the
      old, for both the first and last 1e10 numbers in [0,2^64-1] and 4e9
      'random' numbers in-between.
      
      Test and verification code on github: https://github.com/Villemoes/dec.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Tested-by: default avatarJeff Epler <jepler@unpythonic.net>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7c43d9a3
  16. 15 Apr, 2015 7 commits
    • Rasmus Villemoes's avatar
      lib/string_helpers.c: change semantics of string_escape_mem · 41416f23
      Rasmus Villemoes authored
      The current semantics of string_escape_mem are inadequate for one of its
      current users, vsnprintf().  If that is to honour its contract, it must
      know how much space would be needed for the entire escaped buffer, and
      string_escape_mem provides no way of obtaining that (short of allocating a
      large enough buffer (~4 times input string) to let it play with, and
      that's definitely a big no-no inside vsnprintf).
      
      So change the semantics for string_escape_mem to be more snprintf-like:
      Return the size of the output that would be generated if the destination
      buffer was big enough, but of course still only write to the part of dst
      it is allowed to, and (contrary to snprintf) don't do '\0'-termination.
      It is then up to the caller to detect whether output was truncated and to
      append a '\0' if desired.  Also, we must output partial escape sequences,
      otherwise a call such as snprintf(buf, 3, "%1pE", "\123") would cause
      printf to write a \0 to buf[2] but leaving buf[0] and buf[1] with whatever
      they previously contained.
      
      This also fixes a bug in the escaped_string() helper function, which used
      to unconditionally pass a length of "end-buf" to string_escape_mem();
      since the latter doesn't check osz for being insanely large, it would
      happily write to dst.  For example, kasprintf(GFP_KERNEL, "something and
      then %pE", ...); is an easy way to trigger an oops.
      
      In test-string_helpers.c, the -ENOMEM test is replaced with testing for
      getting the expected return value even if the buffer is too small.  We
      also ensure that nothing is written (by relying on a NULL pointer deref)
      if the output size is 0 by passing NULL - this has to work for
      kasprintf("%pE") to work.
      
      In net/sunrpc/cache.c, I think qword_add still has the same semantics.
      Someone should definitely double-check this.
      
      In fs/proc/array.c, I made the minimum possible change, but longer-term it
      should stop poking around in seq_file internals.
      
      [andriy.shevchenko@linux.intel.com: simplify qword_add]
      [andriy.shevchenko@linux.intel.com: add missed curly braces]
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Acked-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      41416f23
    • Rasmus Villemoes's avatar
      lib/vsprintf.c: fix potential NULL deref in hex_string · 9c98f235
      Rasmus Villemoes authored
      The helper hex_string() is broken in two ways.  First, it doesn't
      increment buf regardless of whether there is room to print, so callers
      such as kasprintf() that try to probe the correct storage to allocate will
      get a too small return value.  But even worse, kasprintf() (and likely
      anyone else trying to find the size of the result) pass NULL for buf and 0
      for size, so we also have end == NULL.  But this means that the end-1 in
      hex_string() is (char*)-1, so buf < end-1 is true and we get a NULL
      pointer deref.  I double-checked this with a trivial kernel module that
      just did a kasprintf(GFP_KERNEL, "%14ph", "CrashBoomBang").
      
      Nobody seems to be using %ph with kasprintf, but we might as well fix it
      before it hits someone.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Acked-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9c98f235
    • Geert Uytterhoeven's avatar
      lib/vsprintf: add %pC{,n,r} format specifiers for clocks · 900cca29
      Geert Uytterhoeven authored
      Add format specifiers for printing struct clk:
        - '%pC' or '%pCn': name (Common Clock Framework) or address (legacy
          clock framework) of the clock,
        - '%pCr': rate of the clock.
      
      [akpm@linux-foundation.org: omit code if !CONFIG_HAVE_CLK]
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Mike Turquette <mturquette@linaro.org>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      900cca29
    • Rasmus Villemoes's avatar
      lib/vsprintf.c: another small hack · d1c1b121
      Rasmus Villemoes authored
      Making ZEROPAD == '0'-' ', we can eliminate a few more instructions.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d1c1b121
    • Rasmus Villemoes's avatar
      lib/vsprintf.c: eliminate duplicate hex string array · 3ea8d440
      Rasmus Villemoes authored
      gcc doesn't merge or overlap const char[] objects with identical contents
      (probably language lawyers would also insist that these things have
      different addresses), but there's no reason to have the string
      "0123456789ABCDEF" occur in multiple places.  hex_asc_upper is declared in
      kernel.h and defined in lib/hexdump.c, which is unconditionally compiled
      in.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3ea8d440
    • Rasmus Villemoes's avatar
      lib/vsprintf.c: reduce stack use in number() · e26c12c7
      Rasmus Villemoes authored
      At least since the initial git commit, when base was passed as a separate
      parameter, number() has only been called with bases 8, 10 and 16.  I'm
      guessing that 66 was to accommodate 64 0/1, a sign and a '\0', but the
      buffer is only used for the actual digits.  Octal digits carry 3 bits of
      information, so 24 is enough.  Spell that 3*sizeof(num) so one less place
      needs to be changed should long long ever be 128 bits.  Also remove the
      commented-out code that would handle an arbitrary base.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e26c12c7
    • Rasmus Villemoes's avatar
      lib/vsprintf.c: eliminate some branches · 51be17df
      Rasmus Villemoes authored
      Since FORMAT_TYPE_INT is simply 1 more than FORMAT_TYPE_UINT, and
      similarly for BYTE/UBYTE, SHORT/USHORT, LONG/ULONG, we can eliminate a few
      instructions by making SIGN have the value 1 instead of 2, and then use
      arithmetic instead of branches for computing the right spec->type.  It's a
      little hacky, but certainly in the same spirit as SMALL needing to have
      the value 0x20.  For example for the spec->qualifier == 'l' case, gcc now
      generates
      
           75e:       0f b6 53 01             movzbl 0x1(%rbx),%edx
           762:       83 e2 01                and    $0x1,%edx
           765:       83 c2 09                add    $0x9,%edx
           768:       88 13                   mov    %dl,(%rbx)
      
      instead of
      
           763:       0f b6 53 01             movzbl 0x1(%rbx),%edx
           767:       83 e2 02                and    $0x2,%edx
           76a:       80 fa 01                cmp    $0x1,%dl
           76d:       19 d2                   sbb    %edx,%edx
           76f:       83 c2 0a                add    $0xa,%edx
           772:       88 13                   mov    %dl,(%rbx)
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      51be17df
  17. 14 Feb, 2015 1 commit
    • Tejun Heo's avatar
      lib/vsprintf: implement bitmap printing through '%*pb[l]' · dbc760bc
      Tejun Heo authored
      bitmap and its derivatives such as cpumask and nodemask currently only
      provide formatting functions which put the output string into the
      provided buffer; however, how long this buffer should be isn't defined
      anywhere and given that some of these bitmaps can be too large to be
      formatted into an on-stack buffer it users sometimes are unnecessarily
      forced to come up with creative solutions and compromises for the
      buffer just to printk these bitmaps.
      
      There have been a couple different attempts at making this easier.
      
      1. Way back, PeterZ tried printk '%pb' extension with the precision
         for bit width - '%.*pb'.  This was intuitive and made sense but
         unfortunately triggered a compile warning about using precision
         for a pointer.
      
         http://lkml.kernel.org/g/1336577562.2527.58.camel@twins
      
      2. I implemented bitmap_pr_cont[_list]() and its wrappers for cpumask
         and nodemask.  This works but PeterZ pointed out that pr_cont's
         tendency to produce broken lines when multiple CPUs are printing is
         bothering considering the usages.
      
         http://lkml.kernel.org/g/1418226774-30215-3-git-send-email-tj@kernel.org
      
      So, this patch is another attempt at teaching printk and friends how
      to print bitmaps.  It's almost identical to what PeterZ tried with
      precision but it uses the field width for the number of bits instead
      of precision.  The format used is '%*pb[l]', with the optional
      trailing 'l' specifying list format instead of hex masks.
      
      This is a valid format string and doesn't trigger compiler warnings;
      however, it does make it impossible to specify output field width when
      printing bitmaps.  I think this is an acceptable trade-off given how
      much easier it makes printing bitmaps and that we don't have any
      in-kernel user which is using the field width specification.  If any
      future user wants to use field width with a bitmap, it'd have to
      format the bitmap into a string buffer and then print that buffer with
      width spec, which isn't different from how it should be done now.
      
      This patch implements bitmap[_list]_string() which are called from the
      vsprintf pointer() formatting function.  The implementation is mostly
      identical to bitmap_scn[list]printf() except that the output is
      performed in the vsprintf way.  These functions handle formatting into
      too small buffers and sprintf() family of functions report the correct
      overrun output length.
      
      bitmap_scn[list]printf() are now thin wrappers around scnprintf().
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dbc760bc
  18. 13 Feb, 2015 3 commits
  19. 14 Oct, 2014 1 commit