2010-12-29 06:25:21 +08:00
|
|
|
/*
|
|
|
|
|
* Persistent Storage - pstore.h
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2010 Intel Corporation <tony.luck@intel.com>
|
|
|
|
|
*
|
|
|
|
|
* This code is the generic layer to export data records from platform
|
|
|
|
|
* level persistent storage via a file system.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
|
*/
|
|
|
|
|
#ifndef _LINUX_PSTORE_H
|
|
|
|
|
#define _LINUX_PSTORE_H
|
|
|
|
|
|
2011-11-18 05:13:29 +08:00
|
|
|
#include <linux/time.h>
|
|
|
|
|
#include <linux/kmsg_dump.h>
|
2012-07-18 02:37:07 +08:00
|
|
|
#include <linux/mutex.h>
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
|
#include <linux/errno.h>
|
2011-11-18 05:13:29 +08:00
|
|
|
|
2010-12-29 06:25:21 +08:00
|
|
|
/* types */
|
|
|
|
|
enum pstore_type_id {
|
|
|
|
|
PSTORE_TYPE_DMESG = 0,
|
|
|
|
|
PSTORE_TYPE_MCE = 1,
|
2012-05-26 21:20:19 +08:00
|
|
|
PSTORE_TYPE_CONSOLE = 2,
|
2012-07-10 08:10:41 +08:00
|
|
|
PSTORE_TYPE_FTRACE = 3,
|
2013-06-06 02:51:44 +08:00
|
|
|
/* PPC64 partition types */
|
|
|
|
|
PSTORE_TYPE_PPC_RTAS = 4,
|
2013-06-06 02:52:10 +08:00
|
|
|
PSTORE_TYPE_PPC_OF = 5,
|
2013-06-06 02:52:20 +08:00
|
|
|
PSTORE_TYPE_PPC_COMMON = 6,
|
2015-01-17 08:01:10 +08:00
|
|
|
PSTORE_TYPE_PMSG = 7,
|
2015-02-06 03:36:28 +08:00
|
|
|
PSTORE_TYPE_PPC_OPAL = 8,
|
2010-12-29 06:25:21 +08:00
|
|
|
PSTORE_TYPE_UNKNOWN = 255
|
|
|
|
|
};
|
|
|
|
|
|
2012-07-18 02:37:07 +08:00
|
|
|
struct module;
|
|
|
|
|
|
2010-12-29 06:25:21 +08:00
|
|
|
struct pstore_info {
|
|
|
|
|
struct module *owner;
|
|
|
|
|
char *name;
|
2011-08-13 01:54:51 +08:00
|
|
|
spinlock_t buf_lock; /* serialize access to 'buf' */
|
2010-12-29 06:25:21 +08:00
|
|
|
char *buf;
|
|
|
|
|
size_t bufsize;
|
2011-11-18 04:58:07 +08:00
|
|
|
struct mutex read_mutex; /* serialize open/read/close */
|
2013-12-19 07:17:10 +08:00
|
|
|
int flags;
|
2011-05-17 02:00:27 +08:00
|
|
|
int (*open)(struct pstore_info *psi);
|
|
|
|
|
int (*close)(struct pstore_info *psi);
|
2011-05-17 01:58:57 +08:00
|
|
|
ssize_t (*read)(u64 *id, enum pstore_type_id *type,
|
efi_pstore: Add a sequence counter to a variable name
[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.
<before applying this patch>
a variable name of first event: dump-type0-1-12345678
a variable name of second event: dump-type0-1-12345678
type:0
id:1
ctime: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
type:0
id:1
sequence counter: 1(first event), 2(second event)
ctime:12345678
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: Seiji Aguchi <seiji.aguchi@hds.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mike Waychison <mikew@google.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
2012-11-27 08:07:44 +08:00
|
|
|
int *count, struct timespec *time, char **buf,
|
2013-08-17 04:53:19 +08:00
|
|
|
bool *compressed, struct pstore_info *psi);
|
2011-11-18 05:13:29 +08:00
|
|
|
int (*write)(enum pstore_type_id type,
|
|
|
|
|
enum kmsg_dump_reason reason, u64 *id,
|
2013-08-17 04:52:47 +08:00
|
|
|
unsigned int part, int count, bool compressed,
|
2013-06-27 16:32:56 +08:00
|
|
|
size_t size, struct pstore_info *psi);
|
2012-07-10 08:10:40 +08:00
|
|
|
int (*write_buf)(enum pstore_type_id type,
|
|
|
|
|
enum kmsg_dump_reason reason, u64 *id,
|
2013-08-17 04:52:47 +08:00
|
|
|
unsigned int part, const char *buf, bool compressed,
|
2013-06-27 16:32:56 +08:00
|
|
|
size_t size, struct pstore_info *psi);
|
2011-07-22 04:57:53 +08:00
|
|
|
int (*erase)(enum pstore_type_id type, u64 id,
|
efi_pstore: Add a sequence counter to a variable name
[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.
<before applying this patch>
a variable name of first event: dump-type0-1-12345678
a variable name of second event: dump-type0-1-12345678
type:0
id:1
ctime: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
type:0
id:1
sequence counter: 1(first event), 2(second event)
ctime:12345678
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: Seiji Aguchi <seiji.aguchi@hds.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mike Waychison <mikew@google.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
2012-11-27 08:07:44 +08:00
|
|
|
int count, struct timespec time,
|
|
|
|
|
struct pstore_info *psi);
|
2011-07-22 04:57:52 +08:00
|
|
|
void *data;
|
2010-12-29 06:25:21 +08:00
|
|
|
};
|
|
|
|
|
|
2013-12-19 07:17:10 +08:00
|
|
|
#define PSTORE_FLAGS_FRAGILE 1
|
|
|
|
|
|
2010-12-29 06:25:21 +08:00
|
|
|
extern int pstore_register(struct pstore_info *);
|
2015-10-20 15:39:03 +08:00
|
|
|
extern void pstore_unregister(struct pstore_info *);
|
pstore: Avoid deadlock in panic and emergency-restart path
[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 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.
[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.
<snip>
/**
* 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)
<snip>
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-01-12 02:09:41 +08:00
|
|
|
extern bool pstore_cannot_block_path(enum kmsg_dump_reason reason);
|
2010-12-29 06:25:21 +08:00
|
|
|
|
|
|
|
|
#endif /*_LINUX_PSTORE_H*/
|