18 Jul, 2012

3 commits

  • 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: Anton Vorontsov
    Signed-off-by: Greg Kroah-Hartman

    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
    (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
     
  • 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: Anton Vorontsov
    Signed-off-by: Greg Kroah-Hartman

    Anton Vorontsov
     

14 Jun, 2012

1 commit

  • Pstore doesn't support logging kernel messages in run-time, it only
    dumps dmesg when kernel oopses/panics. This makes pstore useless for
    debugging hangs caused by HW issues or improper use of HW (e.g.
    weird device inserted -> driver tried to write a reserved bits ->
    SoC hanged. In that case we don't get any messages in the pstore.

    Therefore, let's add a runtime logging support: PSTORE_TYPE_CONSOLE.

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

    Anton Vorontsov
     

18 Nov, 2011

2 commits

  • 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: Kees Cook
    Signed-off-by: Tony Luck

    Kees Cook
     
  • 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] [] __might_sleep+0xc3/0xca
    [ 59.691019] [] kmem_cache_alloc+0x32/0xf3
    [ 59.691019] [] ? __d_lookup_rcu+0x6f/0xf4
    [ 59.691019] [] alloc_inode+0x2a/0x64
    [ 59.691019] [] new_inode+0x18/0x43
    [ 59.691019] [] pstore_get_inode.isra.1+0x11/0x98
    [ 59.691019] [] pstore_mkfile+0xae/0x26f
    [ 59.691019] [] ? kmem_cache_free+0x19/0xb1
    [ 59.691019] [] ? ida_get_new_above+0x140/0x158
    [ 59.691019] [] ? __init_rwsem+0x1e/0x2c
    [ 59.691019] [] ? inode_init_always+0x111/0x1b0
    [ 59.691019] [] ? should_resched+0xd/0x27
    [ 59.691019] [] ? _cond_resched+0xd/0x21
    [ 59.691019] [] pstore_get_records+0x52/0xa7
    [ 59.691019] [] pstore_fill_super+0x7d/0x91
    [ 59.691019] [] mount_single+0x46/0x82
    [ 59.691019] [] pstore_mount+0x15/0x17
    [ 59.691019] [] ? pstore_get_inode.isra.1+0x98/0x98
    [ 59.691019] [] mount_fs+0x5a/0x12d
    [ 59.691019] [] ? alloc_vfsmnt+0xa4/0x14a
    [ 59.691019] [] vfs_kern_mount+0x4f/0x7d
    [ 59.691019] [] do_kern_mount+0x34/0xb2
    [ 59.691019] [] do_mount+0x5fc/0x64a
    [ 59.691019] [] ? strndup_user+0x2e/0x3f
    [ 59.691019] [] sys_mount+0x66/0x99
    [ 59.691019] [] sysenter_do_call+0x12/0x26

    Signed-off-by: Kees Cook
    Signed-off-by: Tony Luck

    Kees Cook
     

13 Oct, 2011

1 commit


17 Aug, 2011

1 commit

  • 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: Don Zickus
    Acked-by: Matthew Garrett
    Signed-off-by: Tony Luck

    Don Zickus
     

23 Jul, 2011

3 commits


17 May, 2011

2 commits

  • Currently after mount/remount operation on pstore filesystem,
    the content on pstore will be lost. It is because current ERST
    implementation doesn't support multi-user usage, which moves
    internal pointer to the end after accessing it. Adding
    multi-user support for pstore usage.

    Signed-off-by: Chen Gong
    Signed-off-by: Tony Luck

    Chen Gong
     
  • the return type of function _read_ in pstore is size_t,
    but in the callback function of _read_, the logic doesn't
    consider it too much, which means if negative value (assuming
    error here) is returned, it will be converted to positive because
    of type casting. ssize_t is enough for this function.

    Signed-off-by: Chen Gong
    Signed-off-by: Tony Luck

    Chen Gong
     

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