1. 22 12月, 2017 1 次提交
    • T
      doc: convert printk-formats.txt to rst · b3ed2321
      Tobin C. Harding 提交于
      Documentation/printk-formats.txt is a candidate for conversion to
      ReStructuredText format. Some effort has already been made to do this
      conversion even thought the suffix is currently .txt
      
      Changes required to complete conversion
      
       - Move printk-formats.txt to core-api/printk-formats.rst
       - Add entry to Documentation/core-api/index.rst
       - Remove entry from Documentation/00-INDEX
       - Fix minor grammatical errors.
       - Order heading adornments as suggested by rst docs.
       - Use 'Passed by reference' uniformly.
       - Update pointer documentation around %px specifier.
       - Fix erroneous double backticks (to commas).
       - Remove extraneous double backticks (suggested by Jonathan Corbet).
       - Simplify documentation for kobject.
      Signed-off-by: NTobin C. Harding <me@tobin.cc>
      [jc: downcased "kernel"]
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      b3ed2321
  2. 30 11月, 2017 1 次提交
    • L
      vsprintf: don't use 'restricted_pointer()' when not restricting · ef0010a3
      Linus Torvalds 提交于
      Instead, just fall back on the new '%p' behavior which hashes the
      pointer.
      
      Otherwise, '%pK' - that was intended to mark a pointer as restricted -
      just ends up leaking pointers that a normal '%p' wouldn't leak.  Which
      just make the whole thing pointless.
      
      I suspect we should actually get rid of '%pK' entirely, and make it just
      work as '%p' regardless, but this is the minimal obvious fix.  People
      who actually use 'kptr_restrict' should weigh in on which behavior they
      want.
      
      Cc: Tobin Harding <me@tobin.cc>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef0010a3
  3. 29 11月, 2017 3 次提交
    • T
      vsprintf: add printk specifier %px · 7b1924a1
      Tobin C. Harding 提交于
      printk specifier %p now hashes all addresses before printing. Sometimes
      we need to see the actual unmodified address. This can be achieved using
      %lx but then we face the risk that if in future we want to change the
      way the Kernel handles printing of pointers we will have to grep through
      the already existent 50 000 %lx call sites. Let's add specifier %px as a
      clear, opt-in, way to print a pointer and maintain some level of
      isolation from all the other hex integer output within the Kernel.
      
      Add printk specifier %px to print the actual unmodified address.
      Signed-off-by: NTobin C. Harding <me@tobin.cc>
      7b1924a1
    • T
      printk: hash addresses printed with %p · ad67b74d
      Tobin C. Harding 提交于
      Currently there exist approximately 14 000 places in the kernel where
      addresses are being printed using an unadorned %p. This potentially
      leaks sensitive information regarding the Kernel layout in memory. Many
      of these calls are stale, instead of fixing every call lets hash the
      address by default before printing. This will of course break some
      users, forcing code printing needed addresses to be updated.
      
      Code that _really_ needs the address will soon be able to use the new
      printk specifier %px to print the address.
      
      For what it's worth, usage of unadorned %p can be broken down as
      follows (thanks to Joe Perches).
      
      $ git grep -E '%p[^A-Za-z0-9]' | cut -f1 -d"/" | sort | uniq -c
         1084 arch
           20 block
           10 crypto
           32 Documentation
         8121 drivers
         1221 fs
          143 include
          101 kernel
           69 lib
          100 mm
         1510 net
           40 samples
            7 scripts
           11 security
          166 sound
          152 tools
            2 virt
      
      Add function ptr_to_id() to map an address to a 32 bit unique
      identifier. Hash any unadorned usage of specifier %p and any malformed
      specifiers.
      Signed-off-by: NTobin C. Harding <me@tobin.cc>
      ad67b74d
    • T
      vsprintf: refactor %pK code out of pointer() · 57e73442
      Tobin C. Harding 提交于
      Currently code to handle %pK is all within the switch statement in
      pointer(). This is the wrong level of abstraction. Each of the other switch
      clauses call a helper function, pK should do the same.
      
      Refactor code out of pointer() to new function restricted_pointer().
      Signed-off-by: NTobin C. Harding <me@tobin.cc>
      57e73442
  4. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  5. 28 6月, 2017 1 次提交
    • P
      vsprintf: Add %p extension "%pOF" for device tree · ce4fecf1
      Pantelis Antoniou 提交于
      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: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
      Acked-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      ce4fecf1
  6. 05 6月, 2017 1 次提交
  7. 09 5月, 2017 1 次提交
  8. 03 4月, 2017 1 次提交
  9. 28 2月, 2017 1 次提交
  10. 21 5月, 2016 2 次提交
  11. 18 3月, 2016 1 次提交
    • J
      sscanf: implement basic character sets · f9310b2f
      Jessica Yu 提交于
      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: NJessica Yu <jeyu@redhat.com>
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f9310b2f
  12. 16 3月, 2016 1 次提交
    • V
      mm, printk: introduce new format string for flags · edf14cdb
      Vlastimil Babka 提交于
      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: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NMichal 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      edf14cdb
  13. 12 2月, 2016 1 次提交
  14. 17 1月, 2016 8 次提交
  15. 07 1月, 2016 1 次提交
  16. 07 11月, 2015 5 次提交
  17. 21 7月, 2015 1 次提交
  18. 17 4月, 2015 2 次提交
    • R
      lib/vsprintf.c: improve put_dec_trunc8 slightly · 675cf53c
      Rasmus Villemoes 提交于
      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: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      675cf53c
    • R
      lib/vsprintf.c: even faster binary to decimal conversion · 7c43d9a3
      Rasmus Villemoes 提交于
      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: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Tested-by: NJeff 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7c43d9a3
  19. 16 4月, 2015 7 次提交
    • R
      lib/string_helpers.c: change semantics of string_escape_mem · 41416f23
      Rasmus Villemoes 提交于
      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: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      41416f23
    • R
      lib/vsprintf.c: fix potential NULL deref in hex_string · 9c98f235
      Rasmus Villemoes 提交于
      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: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9c98f235
    • G
      lib/vsprintf: add %pC{,n,r} format specifiers for clocks · 900cca29
      Geert Uytterhoeven 提交于
      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: NGeert 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      900cca29
    • R
      lib/vsprintf.c: another small hack · d1c1b121
      Rasmus Villemoes 提交于
      Making ZEROPAD == '0'-' ', we can eliminate a few more instructions.
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d1c1b121
    • R
      lib/vsprintf.c: eliminate duplicate hex string array · 3ea8d440
      Rasmus Villemoes 提交于
      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: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ea8d440
    • R
      lib/vsprintf.c: reduce stack use in number() · e26c12c7
      Rasmus Villemoes 提交于
      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: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e26c12c7
    • R
      lib/vsprintf.c: eliminate some branches · 51be17df
      Rasmus Villemoes 提交于
      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: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      51be17df