2005-06-26 05:58:19 +08:00
|
|
|
#ifndef LINUX_CRASH_DUMP_H
|
|
|
|
#define LINUX_CRASH_DUMP_H
|
|
|
|
|
|
|
|
#ifdef CONFIG_CRASH_DUMP
|
|
|
|
#include <linux/kexec.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/proc_fs.h>
|
|
|
|
|
2005-06-26 05:58:21 +08:00
|
|
|
#define ELFCORE_ADDR_MAX (-1ULL)
|
kdump: add is_vmcore_usable() and vmcore_unusable()
The usage of elfcorehdr_addr has changed recently such that being set to
ELFCORE_ADDR_MAX is used by is_kdump_kernel() to indicate if the code is
executing in a kernel executed as a crash kernel.
However, arch/ia64/kernel/setup.c:reserve_elfcorehdr will rest
elfcorehdr_addr to ELFCORE_ADDR_MAX on error, which means any subsequent
calls to is_kdump_kernel() will return 0, even though they should return
1.
Ok, at this point in time there are no subsequent calls, but I think its
fair to say that there is ample scope for error or at the very least
confusion.
This patch add an extra state, ELFCORE_ADDR_ERR, which indicates that
elfcorehdr_addr was passed on the command line, and thus execution is
taking place in a crashdump kernel, but vmcore can't be used for some
reason. This is tested for using is_vmcore_usable() and set using
vmcore_unusable(). A subsequent patch makes use of this new code.
To summarise, the states that elfcorehdr_addr can now be in are as follows:
ELFCORE_ADDR_MAX: not a crashdump kernel
ELFCORE_ADDR_ERR: crashdump kernel but vmcore is unusable
any other value: crash dump kernel and vmcore is usable
Signed-off-by: Simon Horman <horms@verge.net.au>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-19 11:28:29 +08:00
|
|
|
#define ELFCORE_ADDR_ERR (-2ULL)
|
2008-07-26 17:22:33 +08:00
|
|
|
|
2005-06-26 05:58:20 +08:00
|
|
|
extern unsigned long long elfcorehdr_addr;
|
2008-07-26 17:22:33 +08:00
|
|
|
|
2005-06-26 05:58:19 +08:00
|
|
|
extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
|
|
|
|
unsigned long, int);
|
2005-06-26 05:58:21 +08:00
|
|
|
|
2007-05-03 01:27:09 +08:00
|
|
|
/* Architecture code defines this if there are other possible ELF
|
|
|
|
* machine types, e.g. on bi-arch capable hardware. */
|
|
|
|
#ifndef vmcore_elf_check_arch_cross
|
|
|
|
#define vmcore_elf_check_arch_cross(x) 0
|
|
|
|
#endif
|
|
|
|
|
2010-11-19 16:29:24 +08:00
|
|
|
/*
|
|
|
|
* Architecture code can redefine this if there are any special checks
|
|
|
|
* needed for 64-bit ELF vmcores. In case of 32-bit only architecture,
|
|
|
|
* this can be set to zero.
|
|
|
|
*/
|
|
|
|
#ifndef vmcore_elf64_check_arch
|
|
|
|
#define vmcore_elf64_check_arch(x) (elf_check_arch(x) || vmcore_elf_check_arch_cross(x))
|
|
|
|
#endif
|
2007-05-03 01:27:09 +08:00
|
|
|
|
2008-10-19 11:28:25 +08:00
|
|
|
/*
|
|
|
|
* is_kdump_kernel() checks whether this kernel is booting after a panic of
|
|
|
|
* previous kernel or not. This is determined by checking if previous kernel
|
|
|
|
* has passed the elf core header address on command line.
|
|
|
|
*
|
|
|
|
* This is not just a test if CONFIG_CRASH_DUMP is enabled or not. It will
|
|
|
|
* return 1 if CONFIG_CRASH_DUMP=y and if kernel is booting after a panic of
|
|
|
|
* previous kernel.
|
|
|
|
*/
|
|
|
|
|
2008-07-25 16:47:55 +08:00
|
|
|
static inline int is_kdump_kernel(void)
|
|
|
|
{
|
|
|
|
return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0;
|
|
|
|
}
|
kdump: add is_vmcore_usable() and vmcore_unusable()
The usage of elfcorehdr_addr has changed recently such that being set to
ELFCORE_ADDR_MAX is used by is_kdump_kernel() to indicate if the code is
executing in a kernel executed as a crash kernel.
However, arch/ia64/kernel/setup.c:reserve_elfcorehdr will rest
elfcorehdr_addr to ELFCORE_ADDR_MAX on error, which means any subsequent
calls to is_kdump_kernel() will return 0, even though they should return
1.
Ok, at this point in time there are no subsequent calls, but I think its
fair to say that there is ample scope for error or at the very least
confusion.
This patch add an extra state, ELFCORE_ADDR_ERR, which indicates that
elfcorehdr_addr was passed on the command line, and thus execution is
taking place in a crashdump kernel, but vmcore can't be used for some
reason. This is tested for using is_vmcore_usable() and set using
vmcore_unusable(). A subsequent patch makes use of this new code.
To summarise, the states that elfcorehdr_addr can now be in are as follows:
ELFCORE_ADDR_MAX: not a crashdump kernel
ELFCORE_ADDR_ERR: crashdump kernel but vmcore is unusable
any other value: crash dump kernel and vmcore is usable
Signed-off-by: Simon Horman <horms@verge.net.au>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-19 11:28:29 +08:00
|
|
|
|
|
|
|
/* is_vmcore_usable() checks if the kernel is booting after a panic and
|
|
|
|
* the vmcore region is usable.
|
|
|
|
*
|
|
|
|
* This makes use of the fact that due to alignment -2ULL is not
|
|
|
|
* a valid pointer, much in the vain of IS_ERR(), except
|
|
|
|
* dealing directly with an unsigned long long rather than a pointer.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static inline int is_vmcore_usable(void)
|
|
|
|
{
|
|
|
|
return is_kdump_kernel() && elfcorehdr_addr != ELFCORE_ADDR_ERR ? 1 : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* vmcore_unusable() marks the vmcore as unusable,
|
|
|
|
* without disturbing the logic of is_kdump_kernel()
|
|
|
|
*/
|
|
|
|
|
|
|
|
static inline void vmcore_unusable(void)
|
|
|
|
{
|
|
|
|
if (is_kdump_kernel())
|
|
|
|
elfcorehdr_addr = ELFCORE_ADDR_ERR;
|
|
|
|
}
|
2008-07-25 16:47:55 +08:00
|
|
|
#else /* !CONFIG_CRASH_DUMP */
|
|
|
|
static inline int is_kdump_kernel(void) { return 0; }
|
2005-06-26 05:58:19 +08:00
|
|
|
#endif /* CONFIG_CRASH_DUMP */
|
2008-07-25 16:47:55 +08:00
|
|
|
|
|
|
|
extern unsigned long saved_max_pfn;
|
2005-06-26 05:58:19 +08:00
|
|
|
#endif /* LINUX_CRASHDUMP_H */
|