1. 17 Mar, 2014 2 commits
  2. 30 Aug, 2013 1 commit
  3. 19 Aug, 2013 3 commits
  4. 01 Jul, 2013 1 commit
  5. 14 Jun, 2013 1 commit
  6. 08 May, 2013 1 commit
  7. 04 Apr, 2013 2 commits
  8. 19 Mar, 2013 1 commit
  9. 11 Mar, 2013 1 commit
  10. 16 Jan, 2013 1 commit
  11. 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>
  12. 13 Dec, 2012 1 commit
  13. 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>
  14. 18 Nov, 2012 1 commit
  15. 17 Nov, 2012 1 commit
  16. 31 Aug, 2012 1 commit
  17. 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>
  18. 17 Jul, 2012 4 commits
  19. 20 Jun, 2012 2 commits
  20. 13 Jun, 2012 6 commits
  21. 17 May, 2012 2 commits
  22. 16 May, 2012 2 commits