1. 17 Dec, 2018 1 commit
    • Kees Cook's avatar
      pstore/ram: Correctly calculate usable PRZ bytes · b718d6be
      Kees Cook authored
      [ Upstream commit 89d328f6 ]
      The actual number of bytes stored in a PRZ is smaller than the
      bytes requested by platform data, since there is a header on each
      PRZ. Additionally, if ECC is enabled, there are trailing bytes used
      as well. Normally this mismatch doesn't matter since PRZs are circular
      buffers and the leading "overflow" bytes are just thrown away. However, in
      the case of a compressed record, this rather badly corrupts the results.
      This corruption was visible with "ramoops.mem_size=204800 ramoops.ecc=1".
      Any stored crashes would not be uncompressable (producing a pstorefs
      "dmesg-*.enc.z" file), and triggering errors at boot:
        [    2.790759] pstore: crypto_comp_decompress failed, ret = -22!
      Backporting this depends on commit 70ad35db
       ("pstore: Convert console
      write to use ->write_buf")
      Reported-by: default avatarJoel Fernandes <joel@joelfernandes.org>
      Fixes: b0aad7a9
       ("pstore: Add compression support to pstore")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
  2. 31 May, 2017 1 commit
  3. 07 Mar, 2017 8 commits
  4. 16 Nov, 2016 1 commit
    • Joel Fernandes's avatar
      pstore: Add ftrace timestamp counter · fbccdeb8
      Joel Fernandes authored
      In preparation for merging the per CPU buffers into one buffer when
      we retrieve the pstore ftrace data, we store the timestamp as a
      counter in the ftrace pstore record.  We store the CPU number as well
      if !PSTORE_CPU_IN_IP, in this case we shift the counter and may lose
      ordering there but we preserve the same record size. The timestamp counter
      is also racy, and not doing any locking or synchronization here results
      in the benefit of lower overhead. Since we don't care much here for exact
      ordering of function traces across CPUs, we don't synchronize and may lose
      some counter updates but I'm ok with that.
      Using trace_clock() results in much lower performance so avoid using it
      since we don't want accuracy in timestamp and need a rough ordering to
      perform merge.
      Signed-off-by: default avatarJoel Fernandes <joelaf@google.com>
      [kees: updated commit message, added comments]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
  5. 08 Sep, 2016 3 commits
    • Mark Salyzyn's avatar
      pstore/pmsg: drop bounce buffer · 5bf6d1b9
      Mark Salyzyn authored
      Removing a bounce buffer copy operation in the pmsg driver path is
      always better. We also gain in overall performance by not requesting
      a vmalloc on every write as this can cause precious RT tasks, such
      as user facing media operation, to stall while memory is being
      reclaimed. Added a write_buf_user to the pstore functions, a backup
      platform write_buf_user that uses the small buffer that is part of
      the instance, and implemented a ramoops write_buf_user that only
      supports PSTORE_TYPE_PMSG.
      Signed-off-by: default avatarMark Salyzyn <salyzyn@android.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
    • Namhyung Kim's avatar
      pstore/ram: Set pstore flags dynamically · 79d955af
      Namhyung Kim authored
      The ramoops can be configured to enable each pstore type by setting
      their size.  In that case, it'd be better not to register disabled types
      in the first place.
      Cc: Anton Vorontsov <anton@enomsg.org>
      Cc: Colin Cross <ccross@android.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
    • Namhyung Kim's avatar
      pstore: Split pstore fragile flags · c950fd6f
      Namhyung Kim authored
      This patch adds new PSTORE_FLAGS for each pstore type so that they can
      be enabled separately.  This is a preparation for ongoing virtio-pstore
      work to support those types flexibly.
      The PSTORE_FLAGS_FRAGILE is changed to PSTORE_FLAGS_DMESG to preserve the
      original behavior.
      Cc: Anton Vorontsov <anton@enomsg.org>
      Cc: Colin Cross <ccross@android.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-efi@vger.kernel.org
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      [kees: retained "FRAGILE" for now to make merges easier]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
  6. 02 Jun, 2016 1 commit
    • Geliang Tang's avatar
      pstore: add lzo/lz4 compression support · 8cfc8ddc
      Geliang Tang authored
      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: default avatarGeliang Tang <geliangtang@163.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
  7. 22 Oct, 2015 1 commit
  8. 23 Mar, 2015 1 commit
  9. 17 Jan, 2015 1 commit
  10. 20 Dec, 2013 1 commit
  11. 19 Aug, 2013 2 commits
  12. 01 Jul, 2013 1 commit
  13. 20 Jun, 2013 3 commits
  14. 11 Jan, 2013 1 commit
    • Seiji Aguchi's avatar
      pstore: Avoid deadlock in panic and emergency-restart path · 9f244e9c
      Seiji Aguchi authored
      When pstore is in panic and emergency-restart paths, it may be blocked
      in those paths because it simply takes spin_lock.
      This is an example scenario which pstore may hang up in a panic path:
       - cpuA grabs psinfo->buf_lock
       - cpuB panics and calls smp_send_stop
       - smp_send_stop sends IRQ to cpuA
       - after 1 second, cpuB gives up on cpuA and sends an NMI instead
       - cpuA is now in an NMI handler while still holding buf_lock
       - cpuB is deadlocked
      This case may happen if a firmware has a bug and
      cpuA is stuck talking with it more than one second.
      Also, this is a similar scenario in an emergency-restart path:
       - cpuA grabs psinfo->buf_lock and stucks in a firmware
       - cpuB kicks emergency-restart via either sysrq-b or hangcheck timer.
         And then, cpuB is deadlocked by taking psinfo->buf_lock again.
      This patch avoids the deadlocking issues in both panic and emergency_restart
      paths by introducing a function, is_non_blocking_path(), to check if a cpu
      can be blocked in current path.
      With this patch, pstore is not blocked even if another cpu has
      taken a spin_lock, in those paths by changing from spin_lock_irqsave
      to spin_trylock_irqsave.
      In addition, according to a comment of emergency_restart() in kernel/sys.c,
      spin_lock shouldn't be taken in an emergency_restart path to avoid
      deadlock. This patch fits the comment below.
       *      emergency_restart - reboot the system
       *      Without shutting down any hardware or taking any locks
       *      reboot the system.  This is called when we know we are in
       *      trouble so this is our best effort to reboot.  This is
       *      safe to call in interrupt context.
      void emergency_restart(void)
      Signed-off-by: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Acked-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  15. 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>
  16. 07 Sep, 2012 1 commit
    • Anton Vorontsov's avatar
      pstore/ftrace: Convert to its own enable/disable debugfs knob · 65f8c95e
      Anton Vorontsov authored
      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
      - 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: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarAnton Vorontsov <anton.vorontsov@linaro.org>
  17. 17 Jul, 2012 3 commits
    • Anton Vorontsov's avatar
      pstore: Headers should include all stuff they use · 67a101f5
      Anton Vorontsov authored
      Headers should really include all the needed prototypes, types, defines
      etc. to be self-contained. This is a long-standing issue, but apparently
      the new tracing code unearthed it (SMP=n is also a prerequisite):
      In file included from fs/pstore/internal.h:4:0,
                       from fs/pstore/ftrace.c:21:
      include/linux/pstore.h:43:15: error: field ‘read_mutex’ has incomplete type
      While at it, I also added the following:
      linux/types.h -> size_t, phys_addr_t, uXX and friends
      linux/spinlock.h -> spinlock_t
      linux/errno.h -> Exxxx
      linux/time.h -> struct timespec (struct passed by value)
      struct module and rs_control forward declaration (passed via pointers).
      Signed-off-by: default avatarAnton Vorontsov <anton.vorontsov@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Anton Vorontsov's avatar
      pstore: Add persistent function tracing · 060287b8
      Anton Vorontsov authored
      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.
      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: default avatarAnton Vorontsov <anton.vorontsov@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Anton Vorontsov's avatar
      pstore: Introduce write_buf backend callback · 897dba02
      Anton Vorontsov authored
      For function tracing we need to stop using pstore.buf directly, since
      in a tracing callback we can't use spinlocks, and thus we can't safely
      use the global buffer.
      With write_buf callback, backends no longer need to access pstore.buf
      directly, and thus we can pass any buffers (e.g. allocated on stack).
      Signed-off-by: default avatarAnton Vorontsov <anton.vorontsov@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. 13 Jun, 2012 1 commit
  19. 17 Nov, 2011 2 commits
    • Kees Cook's avatar
      pstore: pass reason to backend write callback · 3d6d8d20
      Kees Cook authored
      This allows a backend to filter on the dmesg reason as well as the pstore
      reason. When ramoops is switched to pstore, this is needed since it has
      no interest in storing non-crash dmesg details.
      Drop pstore_write() as it has no users, and handling the "reason" here
      has no obviously correct value.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
    • Kees Cook's avatar
      pstore: pass allocated memory region back to caller · f6f82851
      Kees Cook authored
      The buf_lock cannot be held while populating the inodes, so make the backend
      pass forward an allocated and filled buffer instead. This solves the following
      backtrace. The effect is that "buf" is only ever used to notify the backends
      that something was written to it, and shouldn't be used in the read path.
      To replace the buf_lock during the read path, isolate the open/read/close
      loop with a separate mutex to maintain serialized access to the backend.
      Note that is is up to the pstore backend to cope if the (*write)() path is
      called in the middle of the read path.
      [   59.691019] BUG: sleeping function called from invalid context at .../mm/slub.c:847
      [   59.691019] in_atomic(): 0, irqs_disabled(): 1, pid: 1819, name: mount
      [   59.691019] Pid: 1819, comm: mount Not tainted 3.0.8 #1
      [   59.691019] Call Trace:
      [   59.691019]  [<810252d5>] __might_sleep+0xc3/0xca
      [   59.691019]  [<810a26e6>] kmem_cache_alloc+0x32/0xf3
      [   59.691019]  [<810b53ac>] ? __d_lookup_rcu+0x6f/0xf4
      [   59.691019]  [<810b68b1>] alloc_inode+0x2a/0x64
      [   59.691019]  [<810b6903>] new_inode+0x18/0x43
      [   59.691019]  [<81142447>] pstore_get_inode.isra.1+0x11/0x98
      [   59.691019]  [<81142623>] pstore_mkfile+0xae/0x26f
      [   59.691019]  [<810a2a66>] ? kmem_cache_free+0x19/0xb1
      [   59.691019]  [<8116c821>] ? ida_get_new_above+0x140/0x158
      [   59.691019]  [<811708ea>] ? __init_rwsem+0x1e/0x2c
      [   59.691019]  [<810b67e8>] ? inode_init_always+0x111/0x1b0
      [   59.691019]  [<8102127e>] ? should_resched+0xd/0x27
      [   59.691019]  [<8137977f>] ? _cond_resched+0xd/0x21
      [   59.691019]  [<81142abf>] pstore_get_records+0x52/0xa7
      [   59.691019]  [<8114254b>] pstore_fill_super+0x7d/0x91
      [   59.691019]  [<810a7ff5>] mount_single+0x46/0x82
      [   59.691019]  [<8114231a>] pstore_mount+0x15/0x17
      [   59.691019]  [<811424ce>] ? pstore_get_inode.isra.1+0x98/0x98
      [   59.691019]  [<810a8199>] mount_fs+0x5a/0x12d
      [   59.691019]  [<810b9174>] ? alloc_vfsmnt+0xa4/0x14a
      [   59.691019]  [<810b9474>] vfs_kern_mount+0x4f/0x7d
      [   59.691019]  [<810b9d7e>] do_kern_mount+0x34/0xb2
      [   59.691019]  [<810bb15f>] do_mount+0x5fc/0x64a
      [   59.691019]  [<810912fb>] ? strndup_user+0x2e/0x3f
      [   59.691019]  [<810bb3cb>] sys_mount+0x66/0x99
      [   59.691019]  [<8137b537>] sysenter_do_call+0x12/0x26
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  20. 12 Oct, 2011 1 commit
  21. 16 Aug, 2011 1 commit
    • Don Zickus's avatar
      pstore: change mutex locking to spin_locks · abd4d558
      Don Zickus authored
      pstore was using mutex locking to protect read/write access to the
      backend plug-ins.  This causes problems when pstore is executed in
      an NMI context through panic() -> kmsg_dump().
      This patch changes the mutex to a spin_lock_irqsave then also checks to
      see if we are in an NMI context.  If we are in an NMI and can't get the
      lock, just print a message stating that and blow by the locking.
      All this is probably a hack around the bigger locking problem but it
      solves my current situation of trying to sleep in an NMI context.
      Tested by loading the lkdtm module and executing a HARDLOCKUP which
      will cause the machine to panic inside the nmi handler.
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Acked-by: default avatarMatthew Garrett <mjg@redhat.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  22. 22 Jul, 2011 3 commits