1. 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
  2. 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
  3. 12 2月, 2016 1 次提交
  4. 17 1月, 2016 8 次提交
  5. 07 1月, 2016 1 次提交
  6. 07 11月, 2015 5 次提交
  7. 21 7月, 2015 1 次提交
  8. 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
  9. 16 4月, 2015 7 次提交
  10. 14 2月, 2015 1 次提交
    • T
      lib/vsprintf: implement bitmap printing through '%*pb[l]' · dbc760bc
      Tejun Heo 提交于
      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: NTejun Heo <tj@kernel.org>
      Acked-by: NPeter 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dbc760bc
  11. 13 2月, 2015 3 次提交
  12. 14 10月, 2014 1 次提交
  13. 09 9月, 2014 1 次提交
  14. 05 6月, 2014 1 次提交
  15. 04 4月, 2014 1 次提交
  16. 27 2月, 2014 1 次提交
    • B
      vsprintf: Add support for IORESOURCE_UNSET in %pR · d19cb803
      Bjorn Helgaas 提交于
      Sometimes we have a struct resource where we know the type (MEM/IO/etc.)
      and the size, but we haven't assigned address space for it.  The
      IORESOURCE_UNSET flag is a way to indicate this situation.  For these
      "unset" resources, the start address is meaningless, so print only the
      size, e.g.,
      
        - pci 0000:0c:00.0: reg 184: [mem 0x00000000-0x00001fff 64bit]
        + pci 0000:0c:00.0: reg 184: [mem size 0x2000 64bit]
      
      For %pr (printing with raw flags), we still print the address range,
      because %pr is mostly used for debugging anyway.
      
      Thanks to Fengguang Wu <fengguang.wu@intel.com> for suggesting
      resource_size().
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d19cb803
  17. 24 1月, 2014 1 次提交
  18. 15 11月, 2013 1 次提交
    • K
      vsprintf: ignore %n again · 9196436a
      Kees Cook 提交于
      This ignores %n in printf again, as was originally documented.
      Implementing %n poses a greater security risk than utility, so it should
      stay ignored.  To help anyone attempting to use %n, a warning will be
      emitted if it is encountered.
      
      Based on an earlier patch by Joe Perches.
      
      Because %n was designed to write to pointers on the stack, it has been
      frequently used as an attack vector when bugs are found that leak
      user-controlled strings into functions that ultimately process format
      strings.  While this class of bug can still be turned into an
      information leak, removing %n eliminates the common method of elevating
      such a bug into an arbitrary kernel memory writing primitive,
      significantly reducing the danger of this class of bug.
      
      For seq_file users that need to know the length of a written string for
      padding, please see seq_setwidth() and seq_pad() instead.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9196436a
  19. 13 11月, 2013 2 次提交
    • O
      lib/vsprintf.c: document formats for dentry and struct file · c0d92a57
      Olof Johansson 提交于
      Looks like these were added to Documentation/printk-formats.txt but
      not the in-file table.
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c0d92a57
    • R
      vsprintf: check real user/group id for %pK · 312b4e22
      Ryan Mallon 提交于
      Some setuid binaries will allow reading of files which have read
      permission by the real user id.  This is problematic with files which
      use %pK because the file access permission is checked at open() time,
      but the kptr_restrict setting is checked at read() time.  If a setuid
      binary opens a %pK file as an unprivileged user, and then elevates
      permissions before reading the file, then kernel pointer values may be
      leaked.
      
      This happens for example with the setuid pppd application on Ubuntu 12.04:
      
        $ head -1 /proc/kallsyms
        00000000 T startup_32
      
        $ pppd file /proc/kallsyms
        pppd: In file /proc/kallsyms: unrecognized option 'c1000000'
      
      This will only leak the pointer value from the first line, but other
      setuid binaries may leak more information.
      
      Fix this by adding a check that in addition to the current process having
      CAP_SYSLOG, that effective user and group ids are equal to the real ids.
      If a setuid binary reads the contents of a file which uses %pK then the
      pointer values will be printed as NULL if the real user is unprivileged.
      
      Update the sysctl documentation to reflect the changes, and also correct
      the documentation to state the kptr_restrict=0 is the default.
      
      This is a only temporary solution to the issue.  The correct solution is
      to do the permission check at open() time on files, and to replace %pK
      with a function which checks the open() time permission.  %pK uses in
      printk should be removed since no sane permission check can be done, and
      instead protected by using dmesg_restrict.
      Signed-off-by: NRyan Mallon <rmallon@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Joe Perches <joe@perches.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      312b4e22
新手
引导
客服 返回
顶部