31 May, 2020

2 commits

  • pstore/blk is similar to pstore/ram, but uses a block device as the
    storage rather than persistent ram.

    The pstore/blk backend solves two common use-cases that used to preclude
    using pstore/ram:
    - not all devices have a battery that could be used to persist
    regular RAM across power failures.
    - most embedded intelligent equipment have no persistent ram, which
    increases costs, instead preferring cheaper solutions, like block
    devices.

    pstore/blk provides separate configurations for the end user and for the
    block drivers. User configuration determines how pstore/blk operates, such
    as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
    and/or module parameters, but module parameter have priority over Kconfig.
    Driver configuration covers all the details about the target block device,
    such as total size of the device and how to perform read/write operations.
    These are provided by block drivers, calling pstore_register_blkdev(),
    including an optional panic_write callback used to bypass regular IO
    APIs in an effort to avoid potentially destabilized kernel code during
    a panic.

    Signed-off-by: WeiXiong Liao
    Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
    Co-developed-by: Kees Cook
    Signed-off-by: Kees Cook

    WeiXiong Liao
     
  • Implement a common set of APIs needed to support pstore storage zones,
    based on how ramoops is designed. This will be used by pstore/blk with
    the intention of migrating pstore/ram in the future.

    Signed-off-by: WeiXiong Liao
    Link: https://lore.kernel.org/lkml/20200511233229.27745-2-keescook@chromium.org/
    Co-developed-by: Kees Cook
    Signed-off-by: Kees Cook

    WeiXiong Liao
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

22 Oct, 2015

1 commit

  • pstore doesn't support unregistering yet. It was marked as TODO.
    This patch adds some code to fix it:
    1) Add functions to unregister kmsg/console/ftrace/pmsg.
    2) Add a function to free compression buffer.
    3) Unmap the memory and free it.
    4) Add a function to unregister pstore filesystem.

    Signed-off-by: Geliang Tang
    Acked-by: Kees Cook
    [Removed __exit annotation from ramoops_remove(). Reported by Arnd Bergmann]
    Signed-off-by: Tony Luck

    Geliang Tang
     

17 Jan, 2015

1 commit

  • A secured user-space accessible pstore object. Writes
    to /dev/pmsg0 are appended to the buffer, on reboot
    the persistent contents are available in
    /sys/fs/pstore/pmsg-ramoops-[ID].

    One possible use is syslogd, or other daemon, can
    write messages, then on reboot provides a means to
    triage user-space activities leading up to a panic
    as a companion to the pstore dmesg or console logs.

    Signed-off-by: Mark Salyzyn
    Acked-by: Kees Cook
    Signed-off-by: Tony Luck

    Mark Salyzyn
     

18 Jul, 2012

1 commit

  • 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
    (according to sign-off history). I reworked the driver a little bit,
    and ported it to pstore.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: Greg Kroah-Hartman

    Anton Vorontsov
     

17 May, 2012

1 commit

  • This is a first step for adding ECC support for pstore RAM backend: we
    will use the persistent_ram routines, kindly provided by Google.

    Basically, persistent_ram is a set of helper routines to deal with the
    [optionally] ECC-protected persistent ram regions.

    A bit of Makefile, Kconfig and header files adjustments were needed
    because of the move.

    Signed-off-by: Anton Vorontsov
    Acked-by: Kees Cook
    Signed-off-by: Greg Kroah-Hartman

    Anton Vorontsov
     

16 May, 2012

1 commit

  • Since ramoops was converted to pstore, it has nothing to do with character
    devices nowadays. Instead, today it is just a RAM backend for pstore.

    The patch just moves things around. There are a few changes were needed
    because of the move:

    1. Kconfig and Makefiles fixups, of course.

    2. In pstore/ram.c we have to play a bit with MODULE_PARAM_PREFIX, this
    is needed to keep user experience the same as with ramoops driver
    (i.e. so that ramoops.foo kernel command line arguments would still
    work).

    Signed-off-by: Anton Vorontsov
    Acked-by: Marco Stornelli
    Acked-by: Kees Cook
    Signed-off-by: Greg Kroah-Hartman

    Anton Vorontsov
     

29 Dec, 2010

1 commit

  • 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: Tony Luck

    Tony Luck