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
23 Mar, 2015
1 commit
-
This patch adds a new PPC64 partition type to be used for opal
specific nvram partition. A new partition type is needed as none
of the existing type matches this partition type.Signed-off-by: Hari Bathini
Reviewed-by: Kees Cook
Signed-off-by: Michael Ellerman
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
21 Dec, 2013
1 commit
-
Some pstore backing devices use on board flash as persistent
storage. These have limited numbers of write cycles so it
is a poor idea to use them from high frequency operations.Signed-off-by: Tony Luck
Signed-off-by: Linus Torvalds
20 Aug, 2013
2 commits
-
Backends will set the flag 'compressed' after reading the log from
persistent store to indicate the data being returned to pstore is
compressed or not.Signed-off-by: Aruna Balakrishnaiah
Reviewed-by: Kees Cook
Signed-off-by: Tony Luck -
Addition of new argument 'compressed' in the write call back will
help the backend to know if the data passed from pstore is compressed
or not (In case where compression fails.). If compressed, the backend
can add a tag indicating the data is compressed while writing to
persistent store.Signed-off-by: Aruna Balakrishnaiah
Reviewed-by: Kees Cook
Signed-off-by: Tony Luck
01 Jul, 2013
1 commit
-
Header size is needed to distinguish between header and the dump data.
Incorporate the addition of new argument (hsize) in the pstore write
callback.Signed-off-by: Aruna Balakrishnaiah
Acked-by: Kees Cook
Signed-off-by: Benjamin Herrenschmidt
20 Jun, 2013
3 commits
-
This patch exploits pstore subsystem to read details of common partition
in NVRAM to a separate file in /dev/pstore. For instance, common partition
details will be stored in a file named [common-nvram-6].Signed-off-by: Aruna Balakrishnaiah
Reviewed-by: Jim Keniston
Signed-off-by: Benjamin Herrenschmidt -
This patch set exploits the pstore subsystem to read details of
of-config partition in NVRAM to a separate file in /dev/pstore.
For instance, of-config partition details will be stored in a
file named [of-nvram-5].Signed-off-by: Aruna Balakrishnaiah
Reviewed-by: Jim Keniston
Signed-off-by: Benjamin Herrenschmidt -
This patch set exploits the pstore subsystem to read details of rtas partition
in NVRAM to a separate file in /dev/pstore. For instance, rtas details will be
stored in a file named [rtas-nvram-4].Signed-off-by: Aruna Balakrishnaiah
Reviewed-by: Jim Keniston
Signed-off-by: Benjamin Herrenschmidt
12 Jan, 2013
1 commit
-
[Issue]
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 deadlockedThis 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.[Solution]
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: Seiji Aguchi
Acked-by: Don Zickus
Signed-off-by: Tony Luck
27 Nov, 2012
2 commits
-
[Issue]
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.[Solution]
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.
a variable name of first event: dump-type0-1-12345678
a variable name of second event: dump-type0-1-12345678type:0
id:1
ctime:12345678If multiple events happen in a short time, efi_pstore can't distinguish them because
variable names are same among them.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-12345678type:0
id:1
sequence counter: 1(first event), 2(second event)
ctime:12345678In 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: Seiji Aguchi
Acked-by: Rafael J. Wysocki
Acked-by: Mike Waychison
Signed-off-by: Tony Luck -
[Issue]
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-23456789type:0
id:1
ctime:12345678, 23456789[Solution]
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: Seiji Aguchi
Acked-by: Mike Waychison
Signed-off-by: Tony Luck
07 Sep, 2012
1 commit
-
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
have:- 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: Steven Rostedt
Signed-off-by: Anton Vorontsov
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 typeWhile 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 -
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 -
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
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
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 -
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/0x26Signed-off-by: Kees Cook
Signed-off-by: Tony Luck
13 Oct, 2011
1 commit
-
Currently pstore write interface employs record id as return
value, but it is not enough because it can't tell caller if
the write operation is successful. Pass the record id back via
an argument pointer and return zero for success, non-zero for
failure.Signed-off-by: Chen Gong
Signed-off-by: Tony Luck
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
23 Jul, 2011
3 commits
-
We'll never have a negative part, so just make this an unsigned int.
Signed-off-by: Matthew Garrett
Signed-off-by: Tony Luck -
EFI only provides small amounts of individual storage, and conventionally
puts metadata in the storage variable name. Rather than add a metadata
header to the (already limited) variable storage, it's easier for us to
modify pstore to pass all the information we need to construct a unique
variable name to the appropriate functions.Signed-off-by: Matthew Garrett
Signed-off-by: Tony Luck -
Some pstore implementations may not have a static context, so extend the
API to pass the pstore_info struct to all calls and allow for a context
pointer.Signed-off-by: Matthew Garrett
Signed-off-by: Tony Luck
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 -
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
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