1. 17 Jan, 2015 1 commit
  2. 16 Jan, 2015 2 commits
  3. 11 Dec, 2014 1 commit
    • Tony Lindgren's avatar
      pstore-ram: Allow optional mapping with pgprot_noncached · 027bc8b0
      Tony Lindgren authored
      On some ARMs the memory can be mapped pgprot_noncached() and still
      be working for atomic operations. As pointed out by Colin Cross
      <ccross@android.com>, in some cases you do want to use
      pgprot_noncached() if the SoC supports it to see a debug printk
      just before a write hanging the system.
      On ARMs, the atomic operations on strongly ordered memory are
      implementation defined. So let's provide an optional kernel parameter
      for configuring pgprot_noncached(), and use pgprot_writecombine() by
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robherring2@gmail.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Anton Vorontsov <anton@enomsg.org>
      Cc: Colin Cross <ccross@android.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  4. 05 Nov, 2014 1 commit
    • Ben Zhang's avatar
      pstore/ram: Strip ramoops header for correct decompression · a28726b4
      Ben Zhang authored
      pstore compression/decompression was added during 3.12.
      The ramoops driver prepends a "====timestamp.timestamp-C|D\n"
      header to the compressed record before handing it over to pstore
      driver which doesn't know about the header. In pstore_decompress(),
      the pstore driver reads the first "==" as a zlib header, so the
      decompression always fails. For example, this causes the driver
      to write /dev/pstore/dmesg-ramoops-0.enc.z instead of
      This patch makes the ramoops driver remove the header before
      pstore decompression.
      Signed-off-by: default avatarBen Zhang <benzh@chromium.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  5. 20 Oct, 2014 1 commit
  6. 17 Mar, 2014 4 commits
  7. 30 Aug, 2013 1 commit
  8. 19 Aug, 2013 3 commits
  9. 01 Jul, 2013 1 commit
  10. 14 Jun, 2013 1 commit
  11. 08 May, 2013 1 commit
  12. 04 Apr, 2013 2 commits
  13. 19 Mar, 2013 1 commit
  14. 11 Mar, 2013 1 commit
  15. 16 Jan, 2013 1 commit
  16. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      pstore: remove __dev* attributes. · f568f6ca
      Greg Kroah-Hartman authored
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      This change removes the use of __devinit from the pstore filesystem.
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Anton Vorontsov <cbouatmailru@gmail.com>
      Cc: Colin Cross <ccross@android.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. 13 Dec, 2012 1 commit
  18. 27 Nov, 2012 2 commits
    • Seiji Aguchi's avatar
      efi_pstore: Add a sequence counter to a variable name · 755d4fe4
      Seiji Aguchi authored
      Currently, a variable name, which identifies each entry, consists of type, id and ctime.
      But if multiple events happens in a short time, a second/third event may fail to log because
      efi_pstore can't distinguish each event with current variable name.
      A reasonable way to identify all events precisely is introducing a sequence counter to
      the variable name.
      The sequence counter has already supported in a pstore layer with "oopscount".
      So, this patch adds it to a variable name.
      Also, it is passed to read/erase callbacks of platform drivers in accordance with
      the modification of the variable name.
        <before applying this patch>
       a variable name of first event: dump-type0-1-12345678
       a variable name of second event: dump-type0-1-12345678
       If multiple events happen in a short time, efi_pstore can't distinguish them because
       variable names are same among them.
        <after applying this patch>
       it can be distinguishable by adding a sequence counter as follows.
       a variable name of first event: dump-type0-1-1-12345678
       a variable name of Second event: dump-type0-1-2-12345678
        sequence counter: 1(first event), 2(second event)
      In case of a write callback executed in pstore_console_write(), "0" is added to
      an argument of the write callback because it just logs all kernel messages and
      doesn't need to care about multiple events.
      Signed-off-by: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarMike Waychison <mikew@google.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
    • Seiji Aguchi's avatar
      efi_pstore: Add ctime to argument of erase callback · a9efd39c
      Seiji Aguchi authored
      Currently, a variable name, which is used to identify each log entry, consists of type,
      id and ctime. But an erase callback does not use ctime.
      If efi_pstore supported just one log, type and id were enough.
      However, in case of supporting multiple logs, it doesn't work because
      it can't distinguish each entry without ctime at erasing time.
       As you can see below, efi_pstore can't differentiate first event from second one without ctime.
       a variable name of first event: dump-type0-1-12345678
       a variable name of second event: dump-type0-1-23456789
        ctime:12345678, 23456789
      This patch adds ctime to an argument of an erase callback.
      It works across reboots because ctime of pstore means the date that the record was originally stored.
      To do this, efi_pstore saves the ctime to variable name at writing time and passes it to pstore
      at reading time.
      Signed-off-by: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Acked-by: default avatarMike Waychison <mikew@google.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  19. 18 Nov, 2012 1 commit
  20. 17 Nov, 2012 1 commit
  21. 31 Aug, 2012 1 commit
  22. 04 Aug, 2012 3 commits
    • Anton Vorontsov's avatar
      pstore/ram: Mark ramoops_pstore_write_buf() as notrace · 24203036
      Anton Vorontsov authored
      write_buf() should be marked as notrace, otherwise it is prone to
      Though, yet the issue is never triggered in real life, because we run
      inside the function tracer, where ftrace does its own recurse protection.
      But it's still no good, plus soon we might switch to our own tracer ops,
      and then the issue will be fatal. So, let's fix it.
      Signed-off-by: default avatarAnton Vorontsov <anton.vorontsov@linaro.org>
    • Randy Dunlap's avatar
      pstore/ram: Fix printk format warning · 0427193b
      Randy Dunlap authored
      Fix printk format warning (on i386) in pstore:
      fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t'
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarAnton Vorontsov <anton.vorontsov@linaro.org>
    • Anton Vorontsov's avatar
      pstore/ram: Fix possible NULL dereference · a384f641
      Anton Vorontsov authored
      We can dereference 'cxt->cprz' if console and dump logging are disabled
      (which is unlikely, but still possible to do). This patch fixes the issue
      by changing the code so that we don't dereference przs at all, we can
      just calculate bufsize from console_size and record_size values.
      Plus, while at it, the patch improves the buffer size calculation.
      After Kay's printk rework, we know the optimal buffer size for console
      logging -- it is LOG_LINE_MAX (defined privately in printk.c). Previously,
      if only console logging was enabled, we would allocate unnecessary large
      buffer in pstore, while we only need LOG_LINE_MAX. (Pstore console logging
      is still capable of handling buffers > LOG_LINE_MAX, it will just do
      multiple calls to psinfo->write).
      Note that I don't export the constant, since we will do even a better
      thing soon: we will switch console logging to a new write_buf API, which
      will eliminate the need for the additional buffer; and so we won't need
      the constant.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarAnton Vorontsov <anton.vorontsov@linaro.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
  23. 17 Jul, 2012 4 commits
  24. 20 Jun, 2012 2 commits
  25. 13 Jun, 2012 2 commits