19 Nov, 2011

1 commit


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

2 commits

  • 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
     
  • Life is simple for all the kernel terminating types of kmsg_dump
    call backs - pstore just saves the tail end of the console log. But
    for "oops" the situation is more complex - the kernel may carry on
    running (possibly for ever). So we'd like to make the logged copy
    of the oops appear in the pstore filesystem - so that the user has
    a handle to clear the entry from the persistent backing store (if
    we don't, the store may fill with "oops" entries (that are also
    safely stashed in /var/log/messages) leaving no space for real
    errors.

    Current code calls pstore_mkfile() immediately. But this may
    not be safe. The oops could have happened with arbitrary locks
    held, or in interrupt or NMI context. So allocating memory and
    calling into generic filesystem code seems unwise.

    This patch defers making the entry appear. At the time
    of the oops, we merely set a flag "pstore_new_entry" noting that
    a new entry has been added. A periodic timer checks once a minute
    to see if the flag is set - if so, it schedules a work queue to
    rescan the backing store and make all new entries appear in the
    pstore filesystem.

    Signed-off-by: Tony Luck

    Luck, Tony
     

23 Jul, 2011

4 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
     

31 Mar, 2011

1 commit


23 Mar, 2011

1 commit

  • pstore_dump() can be called with many different "reason" codes. Save
    the name of the code in the persistent store record.

    Also - only worthwhile calling pstore_mkfile for KMSG_DUMP_OOPS - that
    is the only one where the kernel will continue running.

    Reviewed-by: Seiji Aguchi
    Signed-off-by: Tony Luck

    Tony Luck
     

22 Mar, 2011

1 commit


21 Mar, 2011

1 commit


18 Mar, 2011

1 commit

  • 1) Change from ->get_sb() to ->mount()
    2) Use mount_single() instead of mount_nodev()
    3) Pulled in ramfs_get_inode() & trimmed to what I need for pstore
    4) Drop the ugly pstore_writefile() Just save data using kmalloc() and
    provide a pstore_file_read() that uses simple_read_from_buffer().

    Signed-off-by: Al Viro

    Tony Luck
     

07 Jan, 2011

1 commit


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