1. 10 3月, 2018 1 次提交
    • G
      pstore: Use crypto compress API · cb3bee03
      Geliang Tang 提交于
      In the pstore compression part, we use zlib/lzo/lz4/lz4hc/842
      compression algorithm API to implement pstore compression backends. But
      there are many repeat codes in these implementations. This patch uses
      crypto compress API to simplify these codes.
      
      1) rewrite allocate_buf_for_compression, free_buf_for_compression,
      pstore_compress, pstore_decompress functions using crypto compress API.
      2) drop compress, decompress, allocate, free functions in pstore_zbackend,
      and add zbufsize function to get each different compress buffer size.
      3) use late_initcall to call ramoops_init later, to make sure the crypto
      subsystem has already initialized.
      4) use 'unsigned int' type instead of 'size_t' in pstore_compress,
      pstore_decompress functions' length arguments.
      5) rename 'zlib' to 'deflate' to follow the crypto API's name convention.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      [kees: tweaked error messages on allocation failures and Kconfig help]
      Signed-off-by: NKees Cook <keescook@chromium.org>
      cb3bee03
  2. 08 3月, 2018 1 次提交
    • K
      pstore: Select compression at runtime · fe1d4758
      Kees Cook 提交于
      To allow for easier build test coverage and run-time testing, this allows
      multiple compression algorithms to be built into pstore. Still only one
      is supported to operate at a time (which can be selected at build time
      or at boot time, similar to how LSMs are selected).
      Signed-off-by: NKees Cook <keescook@chromium.org>
      fe1d4758
  3. 07 3月, 2018 1 次提交
  4. 24 10月, 2016 1 次提交
  5. 03 6月, 2016 1 次提交
    • G
      pstore: add lzo/lz4 compression support · 8cfc8ddc
      Geliang Tang 提交于
      Like zlib compression in pstore, this patch added lzo and lz4
      compression support so that users can have more options and better
      compression ratio.
      
      The original code treats the compressed data together with the
      uncompressed ECC correction notice by using zlib decompress. The
      ECC correction notice is missing in the decompression process. The
      treatment also makes lzo and lz4 not working. So I treat them
      separately by using pstore_decompress() to treat the compressed
      data, and memcpy() to treat the uncompressed ECC correction notice.
      Signed-off-by: NGeliang Tang <geliangtang@163.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      8cfc8ddc
  6. 22 10月, 2015 1 次提交
  7. 17 1月, 2015 1 次提交
  8. 20 8月, 2013 1 次提交
  9. 07 9月, 2012 1 次提交
    • A
      pstore/ftrace: Convert to its own enable/disable debugfs knob · 65f8c95e
      Anton Vorontsov 提交于
      With this patch we no longer reuse function tracer infrastructure, now
      we register our own tracer back-end via a debugfs knob.
      
      It's a bit more code, but that is the only downside. On the bright side we
      have:
      
      - Ability to make persistent_ram module removable (when needed, we can
        move ftrace_ops struct into a module). Note that persistent_ram is still
        not removable for other reasons, but with this patch it's just one
        thing less to worry about;
      
      - Pstore part is more isolated from the generic function tracer. We tried
        it already by registering our own tracer in available_tracers, but that
        way we're loosing ability to see the traces while we record them to
        pstore. This solution is somewhere in the middle: we only register
        "internal ftracer" back-end, but not the "front-end";
      
      - When there is only pstore tracing enabled, the kernel will only write
        to the pstore buffer, omitting function tracer buffer (which, of course,
        still can be enabled via 'echo function > current_tracer').
      Suggested-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
      65f8c95e
  10. 18 7月, 2012 1 次提交
    • A
      pstore: Add persistent function tracing · 060287b8
      Anton Vorontsov 提交于
      With this support kernel can save function call chain log into a
      persistent ram buffer that can be decoded and dumped after reboot
      through pstore filesystem. It can be used to determine what function
      was last called before a reset or panic.
      
      We store the log in a binary format and then decode it at read time.
      
      p.s.
      Mostly the code comes from trace_persistent.c driver found in the
      Android git tree, written by Colin Cross <ccross@android.com>
      (according to sign-off history). I reworked the driver a little bit,
      and ported it to pstore.
      Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      060287b8
  11. 14 6月, 2012 1 次提交
  12. 17 5月, 2012 1 次提交
  13. 16 5月, 2012 1 次提交
  14. 31 3月, 2011 1 次提交
  15. 29 12月, 2010 1 次提交
    • T
      pstore: new filesystem interface to platform persistent storage · ca01d6dd
      Tony Luck 提交于
      Some platforms have a small amount of non-volatile storage that
      can be used to store information useful to diagnose the cause of
      a system crash.  This is the generic part of a file system interface
      that presents information from the crash as a series of files in
      /dev/pstore.  Once the information has been seen, the underlying
      storage is freed by deleting the files.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      ca01d6dd