2019-05-27 06:55:05 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2012-02-16 01:14:22 +00:00
|
|
|
/*
|
|
|
|
* Firmware Assisted dump: A robust mechanism to get reliable kernel crash
|
|
|
|
* dump with assistance from firmware. This approach does not use kexec,
|
|
|
|
* instead firmware assists in booting the kdump kernel while preserving
|
|
|
|
* memory contents. The most of the code implementation has been adapted
|
|
|
|
* from phyp assisted dump implementation written by Linas Vepstas and
|
|
|
|
* Manish Ahuja
|
|
|
|
*
|
|
|
|
* Copyright 2011 IBM Corporation
|
|
|
|
* Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#undef DEBUG
|
|
|
|
#define pr_fmt(fmt) "fadump: " fmt
|
|
|
|
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/memblock.h>
|
2012-02-20 02:15:03 +00:00
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/seq_file.h>
|
2012-02-16 01:14:37 +00:00
|
|
|
#include <linux/crash_dump.h>
|
2012-02-16 01:15:08 +00:00
|
|
|
#include <linux/kobject.h>
|
|
|
|
#include <linux/sysfs.h>
|
2018-08-17 20:40:56 +00:00
|
|
|
#include <linux/slab.h>
|
powerpc/fadump: Reservationless firmware assisted dump
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is insufficient, or
if the reserved memory was DLPAR hot-removed.
In the normal case, post reboot, the preserved memory is filtered to
extract only relevant areas of interest using the makedumpfile tool.
While the tool provides flexibility to determine what needs to be part
of the dump and what memory to filter out, all supported distributions
default this to "Capture only kernel data and nothing else".
We take advantage of this default and the Linux kernel's Contiguous
Memory Allocator (CMA) to fundamentally change the memory reservation
model for fadump.
Instead of setting aside a significant chunk of memory nobody can use,
this patch uses CMA instead, to reserve a significant chunk of memory
that the kernel is prevented from using (due to MIGRATE_CMA), but
applications are free to use it. With this fadump will still be able
to capture all of the kernel memory and most of the user space memory
except the user pages that were present in CMA region.
Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 7557 193 6822 12 541 6725
Swap: 4095 0 4095
With this patch:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 8133 194 7464 12 475 7338
Swap: 4095 0 4095
Changes made here are completely transparent to how fadump has
traditionally worked.
Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand
CMA and its usage.
TODO:
- Handle case where CMA reservation spans nodes.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-20 08:17:17 +00:00
|
|
|
#include <linux/cma.h>
|
2019-04-26 05:59:47 +00:00
|
|
|
#include <linux/hugetlb.h>
|
2012-02-16 01:14:22 +00:00
|
|
|
|
2017-02-10 01:04:56 +00:00
|
|
|
#include <asm/debugfs.h>
|
2012-02-16 01:14:22 +00:00
|
|
|
#include <asm/page.h>
|
|
|
|
#include <asm/prom.h>
|
|
|
|
#include <asm/fadump.h>
|
2019-09-11 14:46:21 +00:00
|
|
|
#include <asm/fadump-internal.h>
|
2012-03-30 14:01:07 +00:00
|
|
|
#include <asm/setup.h>
|
2012-02-16 01:14:22 +00:00
|
|
|
|
|
|
|
static struct fw_dump fw_dump;
|
2012-02-20 02:15:03 +00:00
|
|
|
|
|
|
|
static DEFINE_MUTEX(fadump_mutex);
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
struct fad_crash_memory_ranges *crash_memory_ranges;
|
|
|
|
int crash_memory_ranges_size;
|
2012-02-16 01:14:37 +00:00
|
|
|
int crash_mem_ranges;
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
int max_crash_mem_ranges;
|
2012-02-16 01:14:22 +00:00
|
|
|
|
powerpc/fadump: Reservationless firmware assisted dump
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is insufficient, or
if the reserved memory was DLPAR hot-removed.
In the normal case, post reboot, the preserved memory is filtered to
extract only relevant areas of interest using the makedumpfile tool.
While the tool provides flexibility to determine what needs to be part
of the dump and what memory to filter out, all supported distributions
default this to "Capture only kernel data and nothing else".
We take advantage of this default and the Linux kernel's Contiguous
Memory Allocator (CMA) to fundamentally change the memory reservation
model for fadump.
Instead of setting aside a significant chunk of memory nobody can use,
this patch uses CMA instead, to reserve a significant chunk of memory
that the kernel is prevented from using (due to MIGRATE_CMA), but
applications are free to use it. With this fadump will still be able
to capture all of the kernel memory and most of the user space memory
except the user pages that were present in CMA region.
Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 7557 193 6822 12 541 6725
Swap: 4095 0 4095
With this patch:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 8133 194 7464 12 475 7338
Swap: 4095 0 4095
Changes made here are completely transparent to how fadump has
traditionally worked.
Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand
CMA and its usage.
TODO:
- Handle case where CMA reservation spans nodes.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-20 08:17:17 +00:00
|
|
|
#ifdef CONFIG_CMA
|
2019-09-11 14:48:14 +00:00
|
|
|
static struct cma *fadump_cma;
|
|
|
|
|
powerpc/fadump: Reservationless firmware assisted dump
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is insufficient, or
if the reserved memory was DLPAR hot-removed.
In the normal case, post reboot, the preserved memory is filtered to
extract only relevant areas of interest using the makedumpfile tool.
While the tool provides flexibility to determine what needs to be part
of the dump and what memory to filter out, all supported distributions
default this to "Capture only kernel data and nothing else".
We take advantage of this default and the Linux kernel's Contiguous
Memory Allocator (CMA) to fundamentally change the memory reservation
model for fadump.
Instead of setting aside a significant chunk of memory nobody can use,
this patch uses CMA instead, to reserve a significant chunk of memory
that the kernel is prevented from using (due to MIGRATE_CMA), but
applications are free to use it. With this fadump will still be able
to capture all of the kernel memory and most of the user space memory
except the user pages that were present in CMA region.
Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 7557 193 6822 12 541 6725
Swap: 4095 0 4095
With this patch:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 8133 194 7464 12 475 7338
Swap: 4095 0 4095
Changes made here are completely transparent to how fadump has
traditionally worked.
Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand
CMA and its usage.
TODO:
- Handle case where CMA reservation spans nodes.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-20 08:17:17 +00:00
|
|
|
/*
|
|
|
|
* fadump_cma_init() - Initialize CMA area from a fadump reserved memory
|
|
|
|
*
|
|
|
|
* This function initializes CMA area from fadump reserved memory.
|
|
|
|
* The total size of fadump reserved memory covers for boot memory size
|
|
|
|
* + cpu data size + hpte size and metadata.
|
|
|
|
* Initialize only the area equivalent to boot memory size for CMA use.
|
|
|
|
* The reamining portion of fadump reserved memory will be not given
|
|
|
|
* to CMA and pages for thoes will stay reserved. boot memory size is
|
|
|
|
* aligned per CMA requirement to satisy cma_init_reserved_mem() call.
|
|
|
|
* But for some reason even if it fails we still have the memory reservation
|
|
|
|
* with us and we can still continue doing fadump.
|
|
|
|
*/
|
|
|
|
int __init fadump_cma_init(void)
|
|
|
|
{
|
|
|
|
unsigned long long base, size;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (!fw_dump.fadump_enabled)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do not use CMA if user has provided fadump=nocma kernel parameter.
|
|
|
|
* Return 1 to continue with fadump old behaviour.
|
|
|
|
*/
|
|
|
|
if (fw_dump.nocma)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
base = fw_dump.reserve_dump_area_start;
|
|
|
|
size = fw_dump.boot_memory_size;
|
|
|
|
|
|
|
|
if (!size)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
rc = cma_init_reserved_mem(base, size, 0, "fadump_cma", &fadump_cma);
|
|
|
|
if (rc) {
|
|
|
|
pr_err("Failed to init cma area for firmware-assisted dump,%d\n", rc);
|
|
|
|
/*
|
|
|
|
* Though the CMA init has failed we still have memory
|
|
|
|
* reservation with us. The reserved memory will be
|
|
|
|
* blocked from production system usage. Hence return 1,
|
|
|
|
* so that we can continue with fadump.
|
|
|
|
*/
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* So we now have successfully initialized cma area for fadump.
|
|
|
|
*/
|
|
|
|
pr_info("Initialized 0x%lx bytes cma area at %ldMB from 0x%lx "
|
|
|
|
"bytes of memory reserved for firmware-assisted dump\n",
|
|
|
|
cma_get_size(fadump_cma),
|
|
|
|
(unsigned long)cma_get_base(fadump_cma) >> 20,
|
|
|
|
fw_dump.reserve_dump_area_size);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static int __init fadump_cma_init(void) { return 1; }
|
|
|
|
#endif /* CONFIG_CMA */
|
|
|
|
|
2012-02-16 01:14:22 +00:00
|
|
|
/* Scan the Firmware Assisted dump configuration details. */
|
2019-09-11 14:49:44 +00:00
|
|
|
int __init early_init_dt_scan_fw_dump(unsigned long node, const char *uname,
|
|
|
|
int depth, void *data)
|
2012-02-16 01:14:22 +00:00
|
|
|
{
|
2019-09-11 14:50:26 +00:00
|
|
|
if (depth != 1)
|
2012-02-16 01:14:22 +00:00
|
|
|
return 0;
|
|
|
|
|
2019-09-11 14:50:26 +00:00
|
|
|
if (strcmp(uname, "rtas") == 0) {
|
|
|
|
rtas_fadump_dt_scan(&fw_dump, node);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (strcmp(uname, "ibm,opal") == 0) {
|
|
|
|
opal_fadump_dt_scan(&fw_dump, node);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2012-02-16 01:14:22 +00:00
|
|
|
}
|
|
|
|
|
2017-06-01 17:21:26 +00:00
|
|
|
/*
|
|
|
|
* If fadump is registered, check if the memory provided
|
2018-08-20 08:17:32 +00:00
|
|
|
* falls within boot memory area and reserved memory area.
|
2017-06-01 17:21:26 +00:00
|
|
|
*/
|
2018-08-20 08:17:32 +00:00
|
|
|
int is_fadump_memory_area(u64 addr, ulong size)
|
2017-06-01 17:21:26 +00:00
|
|
|
{
|
2018-08-20 08:17:32 +00:00
|
|
|
u64 d_start = fw_dump.reserve_dump_area_start;
|
|
|
|
u64 d_end = d_start + fw_dump.reserve_dump_area_size;
|
|
|
|
|
2017-06-01 17:21:26 +00:00
|
|
|
if (!fw_dump.dump_registered)
|
|
|
|
return 0;
|
|
|
|
|
2018-08-20 08:17:32 +00:00
|
|
|
if (((addr + size) > d_start) && (addr <= d_end))
|
|
|
|
return 1;
|
|
|
|
|
2017-06-01 17:21:26 +00:00
|
|
|
return (addr + size) > RMA_START && addr <= fw_dump.boot_memory_size;
|
|
|
|
}
|
|
|
|
|
powerpc/powernv: Use kernel crash path for machine checks
There are quite a few machine check exceptions that can be caused by
kernel bugs. To make debugging easier, use the kernel crash path in
cases of synchronous machine checks that occur in kernel mode, if that
would not result in the machine going straight to panic or crash dump.
There is a downside here that die()ing the process in kernel mode can
still leave the system unstable. panic_on_oops will always force the
system to fail-stop, so systems where that behaviour is important will
still do the right thing.
As a test, when triggering an i-side 0111b error (ifetch from foreign
address) in kernel mode process context on POWER9, the kernel currently
dies quickly like this:
Severe Machine check interrupt [Not recovered]
NIP [ffff000000000000]: 0xffff000000000000
Initiator: CPU
Error type: Real address [Instruction fetch (foreign)]
[ 127.426651616,0] OPAL: Reboot requested due to Platform error.
Effective[ 127.426693712,3] OPAL: Reboot requested due to Platform error. address: ffff000000000000
opal: Reboot type 1 not supported
Kernel panic - not syncing: PowerNV Unrecovered Machine Check
CPU: 56 PID: 4425 Comm: syscall Tainted: G M 4.12.0-rc1-13857-ga4700a261072-dirty #35
Call Trace:
[ 128.017988928,4] IPMI: BUG: Dropping ESEL on the floor due to
buggy/mising code in OPAL for this BMC
Rebooting in 10 seconds..
Trying to free IRQ 496 from IRQ context!
After this patch, the process is killed and the kernel continues with
this message, which gives enough information to identify the offending
branch (i.e., with CFAR):
Severe Machine check interrupt [Not recovered]
NIP [ffff000000000000]: 0xffff000000000000
Initiator: CPU
Error type: Real address [Instruction fetch (foreign)]
Effective address: ffff000000000000
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=2048
NUMA
PowerNV
Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 ...
CPU: 22 PID: 4436 Comm: syscall Tainted: G M 4.12.0-rc1-13857-ga4700a261072-dirty #36
task: c000000932300000 task.stack: c000000932380000
NIP: ffff000000000000 LR: 00000000217706a4 CTR: ffff000000000000
REGS: c00000000fc8fd80 TRAP: 0200 Tainted: G M (4.12.0-rc1-13857-ga4700a261072-dirty)
MSR: 90000000001c1003 <SF,HV,ME,RI,LE>
CR: 24000484 XER: 20000000
CFAR: c000000000004c80 DAR: 0000000021770a90 DSISR: 0a000000 SOFTE: 1
GPR00: 0000000000001ebe 00007fffce4818b0 0000000021797f00 0000000000000000
GPR04: 00007fff8007ac24 0000000044000484 0000000000004000 00007fff801405e8
GPR08: 900000000280f033 0000000024000484 0000000000000000 0000000000000030
GPR12: 9000000000001003 00007fff801bc370 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR28: 00007fff801b0000 0000000000000000 00000000217707a0 00007fffce481918
NIP [ffff000000000000] 0xffff000000000000
LR [00000000217706a4] 0x217706a4
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-19 06:59:11 +00:00
|
|
|
int should_fadump_crash(void)
|
|
|
|
{
|
|
|
|
if (!fw_dump.dump_registered || !fw_dump.fadumphdr_addr)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2012-02-20 02:15:03 +00:00
|
|
|
int is_fadump_active(void)
|
|
|
|
{
|
|
|
|
return fw_dump.dump_active;
|
|
|
|
}
|
|
|
|
|
2017-06-01 17:22:10 +00:00
|
|
|
/*
|
2019-09-11 14:46:36 +00:00
|
|
|
* Returns true, if there are no holes in memory area between d_start to d_end,
|
|
|
|
* false otherwise.
|
2017-06-01 17:22:10 +00:00
|
|
|
*/
|
2019-09-11 14:46:36 +00:00
|
|
|
static bool is_fadump_mem_area_contiguous(u64 d_start, u64 d_end)
|
2017-06-01 17:22:10 +00:00
|
|
|
{
|
|
|
|
struct memblock_region *reg;
|
2019-09-11 14:46:36 +00:00
|
|
|
bool ret = false;
|
|
|
|
u64 start, end;
|
2017-06-01 17:22:10 +00:00
|
|
|
|
|
|
|
for_each_memblock(memory, reg) {
|
2019-09-11 14:46:36 +00:00
|
|
|
start = max_t(u64, d_start, reg->base);
|
|
|
|
end = min_t(u64, d_end, (reg->base + reg->size));
|
|
|
|
if (d_start < end) {
|
|
|
|
/* Memory hole from d_start to start */
|
|
|
|
if (start > d_start)
|
2017-06-01 17:22:10 +00:00
|
|
|
break;
|
|
|
|
|
2019-09-11 14:46:36 +00:00
|
|
|
if (end == d_end) {
|
|
|
|
ret = true;
|
2017-06-01 17:22:10 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-09-11 14:46:36 +00:00
|
|
|
d_start = end + 1;
|
2017-06-01 17:22:10 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-09-11 14:46:36 +00:00
|
|
|
/*
|
|
|
|
* Returns true, if there are no holes in boot memory area,
|
|
|
|
* false otherwise.
|
|
|
|
*/
|
2019-09-11 14:46:52 +00:00
|
|
|
bool is_fadump_boot_mem_contiguous(void)
|
2019-09-11 14:46:36 +00:00
|
|
|
{
|
|
|
|
return is_fadump_mem_area_contiguous(0, fw_dump.boot_memory_size);
|
|
|
|
}
|
|
|
|
|
2018-08-20 08:17:24 +00:00
|
|
|
/*
|
|
|
|
* Returns true, if there are no holes in reserved memory area,
|
|
|
|
* false otherwise.
|
|
|
|
*/
|
2019-09-11 14:46:52 +00:00
|
|
|
bool is_fadump_reserved_mem_contiguous(void)
|
2018-08-20 08:17:24 +00:00
|
|
|
{
|
2019-09-11 14:46:36 +00:00
|
|
|
u64 d_start, d_end;
|
2018-08-20 08:17:24 +00:00
|
|
|
|
2019-09-11 14:46:36 +00:00
|
|
|
d_start = fw_dump.reserve_dump_area_start;
|
|
|
|
d_end = d_start + fw_dump.reserve_dump_area_size;
|
|
|
|
return is_fadump_mem_area_contiguous(d_start, d_end);
|
2018-08-20 08:17:24 +00:00
|
|
|
}
|
|
|
|
|
2012-02-20 02:15:03 +00:00
|
|
|
/* Print firmware assisted dump configurations for debugging purpose. */
|
|
|
|
static void fadump_show_config(void)
|
|
|
|
{
|
|
|
|
pr_debug("Support for firmware-assisted dump (fadump): %s\n",
|
|
|
|
(fw_dump.fadump_supported ? "present" : "no support"));
|
|
|
|
|
|
|
|
if (!fw_dump.fadump_supported)
|
|
|
|
return;
|
|
|
|
|
|
|
|
pr_debug("Fadump enabled : %s\n",
|
|
|
|
(fw_dump.fadump_enabled ? "yes" : "no"));
|
|
|
|
pr_debug("Dump Active : %s\n",
|
|
|
|
(fw_dump.dump_active ? "yes" : "no"));
|
|
|
|
pr_debug("Dump section sizes:\n");
|
|
|
|
pr_debug(" CPU state data size: %lx\n", fw_dump.cpu_state_data_size);
|
|
|
|
pr_debug(" HPTE region size : %lx\n", fw_dump.hpte_region_size);
|
|
|
|
pr_debug("Boot memory size : %lx\n", fw_dump.boot_memory_size);
|
|
|
|
}
|
|
|
|
|
2012-02-16 01:14:22 +00:00
|
|
|
/**
|
|
|
|
* fadump_calculate_reserve_size(): reserve variable boot area 5% of System RAM
|
|
|
|
*
|
|
|
|
* Function to find the largest memory size we need to reserve during early
|
|
|
|
* boot process. This will be the size of the memory that is required for a
|
|
|
|
* kernel to boot successfully.
|
|
|
|
*
|
|
|
|
* This function has been taken from phyp-assisted dump feature implementation.
|
|
|
|
*
|
|
|
|
* returns larger of 256MB or 5% rounded down to multiples of 256MB.
|
|
|
|
*
|
|
|
|
* TODO: Come up with better approach to find out more accurate memory size
|
|
|
|
* that is required for a kernel to boot successfully.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static inline unsigned long fadump_calculate_reserve_size(void)
|
|
|
|
{
|
2017-05-08 22:56:28 +00:00
|
|
|
int ret;
|
|
|
|
unsigned long long base, size;
|
2012-02-16 01:14:22 +00:00
|
|
|
|
2017-05-22 09:34:23 +00:00
|
|
|
if (fw_dump.reserve_bootvar)
|
|
|
|
pr_warn("'fadump_reserve_mem=' parameter is deprecated in favor of 'crashkernel=' parameter.\n");
|
|
|
|
|
2012-02-16 01:14:22 +00:00
|
|
|
/*
|
2017-05-08 22:56:28 +00:00
|
|
|
* Check if the size is specified through crashkernel= cmdline
|
2017-05-22 09:34:47 +00:00
|
|
|
* option. If yes, then use that but ignore base as fadump reserves
|
|
|
|
* memory at a predefined offset.
|
2012-02-16 01:14:22 +00:00
|
|
|
*/
|
2017-05-08 22:56:28 +00:00
|
|
|
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
|
|
|
|
&size, &base);
|
|
|
|
if (ret == 0 && size > 0) {
|
powerpc/fadump: Set an upper limit for boot memory size
By default, 5% of system RAM is reserved for preserving boot memory.
Alternatively, a user can specify the amount of memory to reserve.
See Documentation/powerpc/firmware-assisted-dump.txt for details. In
addition to the memory reserved for preserving boot memory, some more
memory is reserved, to save HPTE region, CPU state data and ELF core
headers.
Memory Reservation during first kernel looks like below:
Low memory Top of memory
0 boot memory size |
| | |<--Reserved dump area -->|
V V | Permanent Reservation V
+-----------+----------/ /----------+---+----+-----------+----+
| | |CPU|HPTE| DUMP |ELF |
+-----------+----------/ /----------+---+----+-----------+----+
| ^
| |
\ /
-------------------------------------------
Boot memory content gets transferred to
reserved area by firmware at the time of
crash
This implicitly means that the sum of the sizes of boot memory, CPU
state data, HPTE region, DUMP preserving area and ELF core headers
can't be greater than the total memory size. But currently, a user is
allowed to specify any value as boot memory size. So, the above rule
is violated when a boot memory size around 50% of the total available
memory is specified. As the kernel is not handling this currently, it
may lead to undefined behavior. Fix it by setting an upper limit for
boot memory size to 25% of the total available memory. Also, instead
of using memblock_end_of_DRAM(), which doesn't take the holes, if any,
in the memory layout into account, use memblock_phys_mem_size() to
calculate the percentage of total available memory.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-06-02 07:30:27 +00:00
|
|
|
unsigned long max_size;
|
|
|
|
|
2017-05-22 09:34:23 +00:00
|
|
|
if (fw_dump.reserve_bootvar)
|
|
|
|
pr_info("Using 'crashkernel=' parameter for memory reservation.\n");
|
|
|
|
|
2017-05-08 22:56:28 +00:00
|
|
|
fw_dump.reserve_bootvar = (unsigned long)size;
|
powerpc/fadump: Set an upper limit for boot memory size
By default, 5% of system RAM is reserved for preserving boot memory.
Alternatively, a user can specify the amount of memory to reserve.
See Documentation/powerpc/firmware-assisted-dump.txt for details. In
addition to the memory reserved for preserving boot memory, some more
memory is reserved, to save HPTE region, CPU state data and ELF core
headers.
Memory Reservation during first kernel looks like below:
Low memory Top of memory
0 boot memory size |
| | |<--Reserved dump area -->|
V V | Permanent Reservation V
+-----------+----------/ /----------+---+----+-----------+----+
| | |CPU|HPTE| DUMP |ELF |
+-----------+----------/ /----------+---+----+-----------+----+
| ^
| |
\ /
-------------------------------------------
Boot memory content gets transferred to
reserved area by firmware at the time of
crash
This implicitly means that the sum of the sizes of boot memory, CPU
state data, HPTE region, DUMP preserving area and ELF core headers
can't be greater than the total memory size. But currently, a user is
allowed to specify any value as boot memory size. So, the above rule
is violated when a boot memory size around 50% of the total available
memory is specified. As the kernel is not handling this currently, it
may lead to undefined behavior. Fix it by setting an upper limit for
boot memory size to 25% of the total available memory. Also, instead
of using memblock_end_of_DRAM(), which doesn't take the holes, if any,
in the memory layout into account, use memblock_phys_mem_size() to
calculate the percentage of total available memory.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-06-02 07:30:27 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Adjust if the boot memory size specified is above
|
|
|
|
* the upper limit.
|
|
|
|
*/
|
|
|
|
max_size = memblock_phys_mem_size() / MAX_BOOT_MEM_RATIO;
|
|
|
|
if (fw_dump.reserve_bootvar > max_size) {
|
|
|
|
fw_dump.reserve_bootvar = max_size;
|
|
|
|
pr_info("Adjusted boot memory size to %luMB\n",
|
|
|
|
(fw_dump.reserve_bootvar >> 20));
|
|
|
|
}
|
|
|
|
|
2012-02-16 01:14:22 +00:00
|
|
|
return fw_dump.reserve_bootvar;
|
2017-05-22 09:34:23 +00:00
|
|
|
} else if (fw_dump.reserve_bootvar) {
|
|
|
|
/*
|
|
|
|
* 'fadump_reserve_mem=' is being used to reserve memory
|
|
|
|
* for firmware-assisted dump.
|
|
|
|
*/
|
|
|
|
return fw_dump.reserve_bootvar;
|
2017-05-08 22:56:28 +00:00
|
|
|
}
|
2012-02-16 01:14:22 +00:00
|
|
|
|
|
|
|
/* divide by 20 to get 5% of value */
|
powerpc/fadump: Set an upper limit for boot memory size
By default, 5% of system RAM is reserved for preserving boot memory.
Alternatively, a user can specify the amount of memory to reserve.
See Documentation/powerpc/firmware-assisted-dump.txt for details. In
addition to the memory reserved for preserving boot memory, some more
memory is reserved, to save HPTE region, CPU state data and ELF core
headers.
Memory Reservation during first kernel looks like below:
Low memory Top of memory
0 boot memory size |
| | |<--Reserved dump area -->|
V V | Permanent Reservation V
+-----------+----------/ /----------+---+----+-----------+----+
| | |CPU|HPTE| DUMP |ELF |
+-----------+----------/ /----------+---+----+-----------+----+
| ^
| |
\ /
-------------------------------------------
Boot memory content gets transferred to
reserved area by firmware at the time of
crash
This implicitly means that the sum of the sizes of boot memory, CPU
state data, HPTE region, DUMP preserving area and ELF core headers
can't be greater than the total memory size. But currently, a user is
allowed to specify any value as boot memory size. So, the above rule
is violated when a boot memory size around 50% of the total available
memory is specified. As the kernel is not handling this currently, it
may lead to undefined behavior. Fix it by setting an upper limit for
boot memory size to 25% of the total available memory. Also, instead
of using memblock_end_of_DRAM(), which doesn't take the holes, if any,
in the memory layout into account, use memblock_phys_mem_size() to
calculate the percentage of total available memory.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-06-02 07:30:27 +00:00
|
|
|
size = memblock_phys_mem_size() / 20;
|
2012-02-16 01:14:22 +00:00
|
|
|
|
|
|
|
/* round it down in multiples of 256 */
|
|
|
|
size = size & ~0x0FFFFFFFUL;
|
|
|
|
|
|
|
|
/* Truncate to memory_limit. We don't want to over reserve the memory.*/
|
|
|
|
if (memory_limit && size > memory_limit)
|
|
|
|
size = memory_limit;
|
|
|
|
|
|
|
|
return (size > MIN_BOOT_MEM ? size : MIN_BOOT_MEM);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the total memory size required to be reserved for
|
|
|
|
* firmware-assisted dump registration.
|
|
|
|
*/
|
|
|
|
static unsigned long get_fadump_area_size(void)
|
|
|
|
{
|
|
|
|
unsigned long size = 0;
|
|
|
|
|
|
|
|
size += fw_dump.cpu_state_data_size;
|
|
|
|
size += fw_dump.hpte_region_size;
|
|
|
|
size += fw_dump.boot_memory_size;
|
2012-02-16 01:14:37 +00:00
|
|
|
size += sizeof(struct fadump_crash_info_header);
|
|
|
|
size += sizeof(struct elfhdr); /* ELF core header.*/
|
2012-02-16 01:14:45 +00:00
|
|
|
size += sizeof(struct elf_phdr); /* place holder for cpu notes */
|
2012-02-16 01:14:37 +00:00
|
|
|
/* Program headers for crash memory regions. */
|
|
|
|
size += sizeof(struct elf_phdr) * (memblock_num_regions(memory) + 2);
|
2012-02-16 01:14:22 +00:00
|
|
|
|
|
|
|
size = PAGE_ALIGN(size);
|
2019-09-11 14:50:57 +00:00
|
|
|
|
|
|
|
/* This is to hold kernel metadata on platforms that support it */
|
|
|
|
size += (fw_dump.ops->fadump_get_metadata_size ?
|
|
|
|
fw_dump.ops->fadump_get_metadata_size() : 0);
|
2012-02-16 01:14:22 +00:00
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
2018-04-10 13:41:16 +00:00
|
|
|
static void __init fadump_reserve_crash_area(unsigned long base,
|
|
|
|
unsigned long size)
|
|
|
|
{
|
|
|
|
struct memblock_region *reg;
|
|
|
|
unsigned long mstart, mend, msize;
|
|
|
|
|
|
|
|
for_each_memblock(memory, reg) {
|
|
|
|
mstart = max_t(unsigned long, base, reg->base);
|
|
|
|
mend = reg->base + reg->size;
|
|
|
|
mend = min(base + size, mend);
|
|
|
|
|
|
|
|
if (mstart < mend) {
|
|
|
|
msize = mend - mstart;
|
|
|
|
memblock_reserve(mstart, msize);
|
|
|
|
pr_info("Reserved %ldMB of memory at %#016lx for saving crash dump\n",
|
|
|
|
(msize >> 20), mstart);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-02-16 01:14:22 +00:00
|
|
|
int __init fadump_reserve_mem(void)
|
|
|
|
{
|
2019-09-11 14:50:41 +00:00
|
|
|
u64 base, size, mem_boundary;
|
|
|
|
int ret = 1;
|
2012-02-16 01:14:22 +00:00
|
|
|
|
|
|
|
if (!fw_dump.fadump_enabled)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!fw_dump.fadump_supported) {
|
2019-09-11 14:50:41 +00:00
|
|
|
pr_info("Firmware-Assisted Dump is not supported on this hardware\n");
|
|
|
|
goto error_out;
|
2012-02-16 01:14:22 +00:00
|
|
|
}
|
2019-09-11 14:50:57 +00:00
|
|
|
|
2012-02-20 02:15:03 +00:00
|
|
|
/*
|
|
|
|
* Initialize boot memory size
|
|
|
|
* If dump is active then we have already calculated the size during
|
|
|
|
* first kernel.
|
|
|
|
*/
|
2019-09-11 14:49:44 +00:00
|
|
|
if (!fw_dump.dump_active) {
|
2019-09-11 14:50:41 +00:00
|
|
|
fw_dump.boot_memory_size =
|
|
|
|
PAGE_ALIGN(fadump_calculate_reserve_size());
|
powerpc/fadump: Reservationless firmware assisted dump
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is insufficient, or
if the reserved memory was DLPAR hot-removed.
In the normal case, post reboot, the preserved memory is filtered to
extract only relevant areas of interest using the makedumpfile tool.
While the tool provides flexibility to determine what needs to be part
of the dump and what memory to filter out, all supported distributions
default this to "Capture only kernel data and nothing else".
We take advantage of this default and the Linux kernel's Contiguous
Memory Allocator (CMA) to fundamentally change the memory reservation
model for fadump.
Instead of setting aside a significant chunk of memory nobody can use,
this patch uses CMA instead, to reserve a significant chunk of memory
that the kernel is prevented from using (due to MIGRATE_CMA), but
applications are free to use it. With this fadump will still be able
to capture all of the kernel memory and most of the user space memory
except the user pages that were present in CMA region.
Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 7557 193 6822 12 541 6725
Swap: 4095 0 4095
With this patch:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 8133 194 7464 12 475 7338
Swap: 4095 0 4095
Changes made here are completely transparent to how fadump has
traditionally worked.
Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand
CMA and its usage.
TODO:
- Handle case where CMA reservation spans nodes.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-20 08:17:17 +00:00
|
|
|
#ifdef CONFIG_CMA
|
|
|
|
if (!fw_dump.nocma)
|
|
|
|
fw_dump.boot_memory_size =
|
|
|
|
ALIGN(fw_dump.boot_memory_size,
|
|
|
|
FADUMP_CMA_ALIGNMENT);
|
|
|
|
#endif
|
|
|
|
}
|
2012-02-16 01:14:22 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the memory boundary.
|
|
|
|
* If memory_limit is less than actual memory boundary then reserve
|
|
|
|
* the memory for fadump beyond the memory_limit and adjust the
|
|
|
|
* memory_limit accordingly, so that the running kernel can run with
|
|
|
|
* specified memory_limit.
|
|
|
|
*/
|
|
|
|
if (memory_limit && memory_limit < memblock_end_of_DRAM()) {
|
|
|
|
size = get_fadump_area_size();
|
|
|
|
if ((memory_limit + size) < memblock_end_of_DRAM())
|
|
|
|
memory_limit += size;
|
|
|
|
else
|
|
|
|
memory_limit = memblock_end_of_DRAM();
|
|
|
|
printk(KERN_INFO "Adjusted memory_limit for firmware-assisted"
|
2012-08-21 01:42:33 +00:00
|
|
|
" dump, now %#016llx\n", memory_limit);
|
2012-02-16 01:14:22 +00:00
|
|
|
}
|
|
|
|
if (memory_limit)
|
2019-09-11 14:50:41 +00:00
|
|
|
mem_boundary = memory_limit;
|
2012-02-16 01:14:22 +00:00
|
|
|
else
|
2019-09-11 14:50:41 +00:00
|
|
|
mem_boundary = memblock_end_of_DRAM();
|
2012-02-16 01:14:22 +00:00
|
|
|
|
2019-09-11 14:50:41 +00:00
|
|
|
base = fw_dump.boot_memory_size;
|
2019-09-11 14:49:28 +00:00
|
|
|
size = get_fadump_area_size();
|
|
|
|
fw_dump.reserve_dump_area_size = size;
|
2012-02-16 01:14:22 +00:00
|
|
|
if (fw_dump.dump_active) {
|
2018-04-10 13:41:16 +00:00
|
|
|
pr_info("Firmware-assisted dump is active.\n");
|
|
|
|
|
2018-04-10 13:41:31 +00:00
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
|
|
|
/*
|
|
|
|
* FADump capture kernel doesn't care much about hugepages.
|
|
|
|
* In fact, handling hugepages in capture kernel is asking for
|
|
|
|
* trouble. So, disable HugeTLB support when fadump is active.
|
|
|
|
*/
|
|
|
|
hugetlb_disabled = true;
|
|
|
|
#endif
|
2012-02-16 01:14:22 +00:00
|
|
|
/*
|
|
|
|
* If last boot has crashed then reserve all the memory
|
|
|
|
* above boot_memory_size so that we don't touch it until
|
|
|
|
* dump is written to disk by userspace tool. This memory
|
|
|
|
* will be released for general use once the dump is saved.
|
|
|
|
*/
|
2019-09-11 14:50:41 +00:00
|
|
|
size = mem_boundary - base;
|
2018-04-10 13:41:16 +00:00
|
|
|
fadump_reserve_crash_area(base, size);
|
2012-02-16 01:14:37 +00:00
|
|
|
|
2019-09-11 14:49:44 +00:00
|
|
|
pr_debug("fadumphdr_addr = %#016lx\n", fw_dump.fadumphdr_addr);
|
|
|
|
pr_debug("Reserve dump area start address: 0x%lx\n",
|
|
|
|
fw_dump.reserve_dump_area_start);
|
2019-09-11 14:49:28 +00:00
|
|
|
} else {
|
2017-03-16 21:05:26 +00:00
|
|
|
/*
|
|
|
|
* Reserve memory at an offset closer to bottom of the RAM to
|
|
|
|
* minimize the impact of memory hot-remove operation. We can't
|
|
|
|
* use memblock_find_in_range() here since it doesn't allocate
|
|
|
|
* from bottom to top.
|
|
|
|
*/
|
2019-09-11 14:50:41 +00:00
|
|
|
while (base <= (mem_boundary - size)) {
|
2017-03-16 21:05:26 +00:00
|
|
|
if (memblock_is_region_memory(base, size) &&
|
|
|
|
!memblock_is_region_reserved(base, size))
|
|
|
|
break;
|
2019-09-11 14:50:41 +00:00
|
|
|
|
|
|
|
base += size;
|
2017-03-16 21:05:26 +00:00
|
|
|
}
|
2019-09-11 14:50:41 +00:00
|
|
|
|
2019-09-11 14:50:57 +00:00
|
|
|
if (base > (mem_boundary - size)) {
|
|
|
|
pr_err("Failed to find memory chunk for reservation!\n");
|
|
|
|
goto error_out;
|
|
|
|
}
|
|
|
|
fw_dump.reserve_dump_area_start = base;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the kernel metadata address and register it with
|
|
|
|
* f/w if the platform supports.
|
|
|
|
*/
|
|
|
|
if (fw_dump.ops->fadump_setup_metadata &&
|
|
|
|
(fw_dump.ops->fadump_setup_metadata(&fw_dump) < 0))
|
|
|
|
goto error_out;
|
|
|
|
|
|
|
|
if (memblock_reserve(base, size)) {
|
2019-09-11 14:50:41 +00:00
|
|
|
pr_err("Failed to reserve memory!\n");
|
|
|
|
goto error_out;
|
2017-03-16 21:05:26 +00:00
|
|
|
}
|
|
|
|
|
2019-09-11 14:50:41 +00:00
|
|
|
pr_info("Reserved %lldMB of memory at %#016llx (System RAM: %lldMB)\n",
|
|
|
|
(size >> 20), base, (memblock_phys_mem_size() >> 20));
|
2017-03-16 21:05:26 +00:00
|
|
|
|
2019-09-11 14:50:41 +00:00
|
|
|
ret = fadump_cma_init();
|
powerpc/fadump: Reservationless firmware assisted dump
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is insufficient, or
if the reserved memory was DLPAR hot-removed.
In the normal case, post reboot, the preserved memory is filtered to
extract only relevant areas of interest using the makedumpfile tool.
While the tool provides flexibility to determine what needs to be part
of the dump and what memory to filter out, all supported distributions
default this to "Capture only kernel data and nothing else".
We take advantage of this default and the Linux kernel's Contiguous
Memory Allocator (CMA) to fundamentally change the memory reservation
model for fadump.
Instead of setting aside a significant chunk of memory nobody can use,
this patch uses CMA instead, to reserve a significant chunk of memory
that the kernel is prevented from using (due to MIGRATE_CMA), but
applications are free to use it. With this fadump will still be able
to capture all of the kernel memory and most of the user space memory
except the user pages that were present in CMA region.
Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 7557 193 6822 12 541 6725
Swap: 4095 0 4095
With this patch:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 8133 194 7464 12 475 7338
Swap: 4095 0 4095
Changes made here are completely transparent to how fadump has
traditionally worked.
Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand
CMA and its usage.
TODO:
- Handle case where CMA reservation spans nodes.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-20 08:17:17 +00:00
|
|
|
}
|
2019-09-11 14:50:41 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
error_out:
|
|
|
|
fw_dump.fadump_enabled = 0;
|
|
|
|
return 0;
|
2012-02-16 01:14:22 +00:00
|
|
|
}
|
|
|
|
|
2016-10-07 23:59:21 +00:00
|
|
|
unsigned long __init arch_reserved_kernel_pages(void)
|
|
|
|
{
|
|
|
|
return memblock_reserved_size() / PAGE_SIZE;
|
|
|
|
}
|
|
|
|
|
2012-02-16 01:14:22 +00:00
|
|
|
/* Look for fadump= cmdline option. */
|
|
|
|
static int __init early_fadump_param(char *p)
|
|
|
|
{
|
|
|
|
if (!p)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
if (strncmp(p, "on", 2) == 0)
|
|
|
|
fw_dump.fadump_enabled = 1;
|
|
|
|
else if (strncmp(p, "off", 3) == 0)
|
|
|
|
fw_dump.fadump_enabled = 0;
|
powerpc/fadump: Reservationless firmware assisted dump
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is insufficient, or
if the reserved memory was DLPAR hot-removed.
In the normal case, post reboot, the preserved memory is filtered to
extract only relevant areas of interest using the makedumpfile tool.
While the tool provides flexibility to determine what needs to be part
of the dump and what memory to filter out, all supported distributions
default this to "Capture only kernel data and nothing else".
We take advantage of this default and the Linux kernel's Contiguous
Memory Allocator (CMA) to fundamentally change the memory reservation
model for fadump.
Instead of setting aside a significant chunk of memory nobody can use,
this patch uses CMA instead, to reserve a significant chunk of memory
that the kernel is prevented from using (due to MIGRATE_CMA), but
applications are free to use it. With this fadump will still be able
to capture all of the kernel memory and most of the user space memory
except the user pages that were present in CMA region.
Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 7557 193 6822 12 541 6725
Swap: 4095 0 4095
With this patch:
[root@zzxx-yy10 ~]# free -m
total used free shared buff/cache available
Mem: 8133 194 7464 12 475 7338
Swap: 4095 0 4095
Changes made here are completely transparent to how fadump has
traditionally worked.
Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand
CMA and its usage.
TODO:
- Handle case where CMA reservation spans nodes.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-20 08:17:17 +00:00
|
|
|
else if (strncmp(p, "nocma", 5) == 0) {
|
|
|
|
fw_dump.fadump_enabled = 1;
|
|
|
|
fw_dump.nocma = 1;
|
|
|
|
}
|
2012-02-16 01:14:22 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("fadump", early_fadump_param);
|
|
|
|
|
2017-05-22 09:34:23 +00:00
|
|
|
/*
|
|
|
|
* Look for fadump_reserve_mem= cmdline option
|
|
|
|
* TODO: Remove references to 'fadump_reserve_mem=' parameter,
|
|
|
|
* the sooner 'crashkernel=' parameter is accustomed to.
|
|
|
|
*/
|
|
|
|
static int __init early_fadump_reserve_mem(char *p)
|
|
|
|
{
|
|
|
|
if (p)
|
|
|
|
fw_dump.reserve_bootvar = memparse(p, &p);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("fadump_reserve_mem", early_fadump_reserve_mem);
|
|
|
|
|
2012-02-16 01:14:45 +00:00
|
|
|
void crash_fadump(struct pt_regs *regs, const char *str)
|
|
|
|
{
|
|
|
|
struct fadump_crash_info_header *fdh = NULL;
|
2016-10-24 18:21:51 +00:00
|
|
|
int old_cpu, this_cpu;
|
2012-02-16 01:14:45 +00:00
|
|
|
|
powerpc/powernv: Use kernel crash path for machine checks
There are quite a few machine check exceptions that can be caused by
kernel bugs. To make debugging easier, use the kernel crash path in
cases of synchronous machine checks that occur in kernel mode, if that
would not result in the machine going straight to panic or crash dump.
There is a downside here that die()ing the process in kernel mode can
still leave the system unstable. panic_on_oops will always force the
system to fail-stop, so systems where that behaviour is important will
still do the right thing.
As a test, when triggering an i-side 0111b error (ifetch from foreign
address) in kernel mode process context on POWER9, the kernel currently
dies quickly like this:
Severe Machine check interrupt [Not recovered]
NIP [ffff000000000000]: 0xffff000000000000
Initiator: CPU
Error type: Real address [Instruction fetch (foreign)]
[ 127.426651616,0] OPAL: Reboot requested due to Platform error.
Effective[ 127.426693712,3] OPAL: Reboot requested due to Platform error. address: ffff000000000000
opal: Reboot type 1 not supported
Kernel panic - not syncing: PowerNV Unrecovered Machine Check
CPU: 56 PID: 4425 Comm: syscall Tainted: G M 4.12.0-rc1-13857-ga4700a261072-dirty #35
Call Trace:
[ 128.017988928,4] IPMI: BUG: Dropping ESEL on the floor due to
buggy/mising code in OPAL for this BMC
Rebooting in 10 seconds..
Trying to free IRQ 496 from IRQ context!
After this patch, the process is killed and the kernel continues with
this message, which gives enough information to identify the offending
branch (i.e., with CFAR):
Severe Machine check interrupt [Not recovered]
NIP [ffff000000000000]: 0xffff000000000000
Initiator: CPU
Error type: Real address [Instruction fetch (foreign)]
Effective address: ffff000000000000
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=2048
NUMA
PowerNV
Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 ...
CPU: 22 PID: 4436 Comm: syscall Tainted: G M 4.12.0-rc1-13857-ga4700a261072-dirty #36
task: c000000932300000 task.stack: c000000932380000
NIP: ffff000000000000 LR: 00000000217706a4 CTR: ffff000000000000
REGS: c00000000fc8fd80 TRAP: 0200 Tainted: G M (4.12.0-rc1-13857-ga4700a261072-dirty)
MSR: 90000000001c1003 <SF,HV,ME,RI,LE>
CR: 24000484 XER: 20000000
CFAR: c000000000004c80 DAR: 0000000021770a90 DSISR: 0a000000 SOFTE: 1
GPR00: 0000000000001ebe 00007fffce4818b0 0000000021797f00 0000000000000000
GPR04: 00007fff8007ac24 0000000044000484 0000000000004000 00007fff801405e8
GPR08: 900000000280f033 0000000024000484 0000000000000000 0000000000000030
GPR12: 9000000000001003 00007fff801bc370 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR28: 00007fff801b0000 0000000000000000 00000000217707a0 00007fffce481918
NIP [ffff000000000000] 0xffff000000000000
LR [00000000217706a4] 0x217706a4
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-19 06:59:11 +00:00
|
|
|
if (!should_fadump_crash())
|
2012-02-16 01:14:45 +00:00
|
|
|
return;
|
|
|
|
|
2016-10-24 18:21:51 +00:00
|
|
|
/*
|
|
|
|
* old_cpu == -1 means this is the first CPU which has come here,
|
|
|
|
* go ahead and trigger fadump.
|
|
|
|
*
|
|
|
|
* old_cpu != -1 means some other CPU has already on it's way
|
|
|
|
* to trigger fadump, just keep looping here.
|
|
|
|
*/
|
|
|
|
this_cpu = smp_processor_id();
|
|
|
|
old_cpu = cmpxchg(&crashing_cpu, -1, this_cpu);
|
|
|
|
|
|
|
|
if (old_cpu != -1) {
|
|
|
|
/*
|
|
|
|
* We can't loop here indefinitely. Wait as long as fadump
|
|
|
|
* is in force. If we race with fadump un-registration this
|
|
|
|
* loop will break and then we go down to normal panic path
|
|
|
|
* and reboot. If fadump is in force the first crashing
|
|
|
|
* cpu will definitely trigger fadump.
|
|
|
|
*/
|
|
|
|
while (fw_dump.dump_registered)
|
|
|
|
cpu_relax();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-02-16 01:14:45 +00:00
|
|
|
fdh = __va(fw_dump.fadumphdr_addr);
|
|
|
|
fdh->crashing_cpu = crashing_cpu;
|
|
|
|
crash_save_vmcoreinfo();
|
|
|
|
|
|
|
|
if (regs)
|
|
|
|
fdh->regs = *regs;
|
|
|
|
else
|
|
|
|
ppc_save_regs(&fdh->regs);
|
|
|
|
|
powerpc/fadump: rename cpu_online_mask member of struct fadump_crash_info_header
The four cpumasks cpu_{possible,online,present,active}_bits are exposed
readonly via the corresponding const variables cpu_xyz_mask. But they are
also accessible for arbitrary writing via the exposed functions
set_cpu_xyz. There's quite a bit of code throughout the kernel which
iterates over or otherwise accesses these bitmaps, and having the access
go via the cpu_xyz_mask variables is nowadays [1] simply a useless
indirection.
It may be that any problem in CS can be solved by an extra level of
indirection, but that doesn't mean every extra indirection solves a
problem. In this case, it even necessitates some minor ugliness (see
4/6).
Patch 1/6 is new in v2, and fixes a build failure on ppc by renaming a
struct member, to avoid problems when the identifier cpu_online_mask
becomes a macro later in the series. The next four patches eliminate the
cpu_xyz_mask variables by simply exposing the actual bitmaps, after
renaming them to discourage direct access - that still happens through
cpu_xyz_mask, which are now simply macros with the same type and value as
they used to have.
After that, there's no longer any reason to have the setter functions be
out-of-line: The boolean parameter is almost always a literal true or
false, so by making them static inlines they will usually compile to one
or two instructions.
For a defconfig build on x86_64, bloat-o-meter says we save ~3000 bytes.
We also save a little stack (stackdelta says 127 functions have a 16 byte
smaller stack frame, while two grow by that amount). Mostly because, when
iterating over the mask, gcc typically loads the value of cpu_xyz_mask
into a callee-saved register and from there into %rdi before each
find_next_bit call - now it can just load the appropriate immediate
address into %rdi before each call.
[1] See Rusty's kind explanation
http://thread.gmane.org/gmane.linux.kernel/2047078/focus=2047722 for
some historic context.
This patch (of 6):
As preparation for eliminating the indirect access to the various global
cpu_*_bits bitmaps via the pointer variables cpu_*_mask, rename the
cpu_online_mask member of struct fadump_crash_info_header to simply
online_mask, thus allowing cpu_online_mask to become a macro.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-01-20 23:00:13 +00:00
|
|
|
fdh->online_mask = *cpu_online_mask;
|
2012-02-16 01:14:45 +00:00
|
|
|
|
2019-09-11 14:48:57 +00:00
|
|
|
fw_dump.ops->fadump_trigger(fdh, str);
|
2012-02-16 01:14:45 +00:00
|
|
|
}
|
|
|
|
|
2019-09-11 14:46:52 +00:00
|
|
|
u32 *fadump_regs_to_elf_notes(u32 *buf, struct pt_regs *regs)
|
2012-02-16 01:14:45 +00:00
|
|
|
{
|
|
|
|
struct elf_prstatus prstatus;
|
|
|
|
|
|
|
|
memset(&prstatus, 0, sizeof(prstatus));
|
|
|
|
/*
|
|
|
|
* FIXME: How do i get PID? Do I really need it?
|
|
|
|
* prstatus.pr_pid = ????
|
|
|
|
*/
|
|
|
|
elf_core_copy_kernel_regs(&prstatus.pr_reg, regs);
|
2017-05-08 22:56:24 +00:00
|
|
|
buf = append_elf_note(buf, CRASH_CORE_NOTE_NAME, NT_PRSTATUS,
|
|
|
|
&prstatus, sizeof(prstatus));
|
2012-02-16 01:14:45 +00:00
|
|
|
return buf;
|
|
|
|
}
|
|
|
|
|
2019-09-11 14:46:52 +00:00
|
|
|
void fadump_update_elfcore_header(char *bufp)
|
2012-02-16 01:14:45 +00:00
|
|
|
{
|
|
|
|
struct elfhdr *elf;
|
|
|
|
struct elf_phdr *phdr;
|
|
|
|
|
|
|
|
elf = (struct elfhdr *)bufp;
|
|
|
|
bufp += sizeof(struct elfhdr);
|
|
|
|
|
|
|
|
/* First note is a place holder for cpu notes info. */
|
|
|
|
phdr = (struct elf_phdr *)bufp;
|
|
|
|
|
|
|
|
if (phdr->p_type == PT_NOTE) {
|
2019-09-11 14:46:36 +00:00
|
|
|
phdr->p_paddr = __pa(fw_dump.cpu_notes_buf_vaddr);
|
2012-02-16 01:14:45 +00:00
|
|
|
phdr->p_offset = phdr->p_paddr;
|
|
|
|
phdr->p_filesz = fw_dump.cpu_notes_buf_size;
|
|
|
|
phdr->p_memsz = fw_dump.cpu_notes_buf_size;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-09-11 14:46:36 +00:00
|
|
|
static void *fadump_alloc_buffer(unsigned long size)
|
2012-02-16 01:14:45 +00:00
|
|
|
{
|
2019-09-11 14:47:56 +00:00
|
|
|
unsigned long count, i;
|
2012-02-16 01:14:45 +00:00
|
|
|
struct page *page;
|
2019-09-11 14:47:56 +00:00
|
|
|
void *vaddr;
|
2012-02-16 01:14:45 +00:00
|
|
|
|
2019-09-11 14:47:56 +00:00
|
|
|
vaddr = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO);
|
2012-02-16 01:14:45 +00:00
|
|
|
if (!vaddr)
|
|
|
|
return NULL;
|
|
|
|
|
2019-09-11 14:47:56 +00:00
|
|
|
count = PAGE_ALIGN(size) / PAGE_SIZE;
|
2012-02-16 01:14:45 +00:00
|
|
|
page = virt_to_page(vaddr);
|
|
|
|
for (i = 0; i < count; i++)
|
2019-09-11 14:47:56 +00:00
|
|
|
mark_page_reserved(page + i);
|
2012-02-16 01:14:45 +00:00
|
|
|
return vaddr;
|
|
|
|
}
|
|
|
|
|
2019-09-11 14:46:36 +00:00
|
|
|
static void fadump_free_buffer(unsigned long vaddr, unsigned long size)
|
2012-02-16 01:14:45 +00:00
|
|
|
{
|
2019-09-11 14:47:56 +00:00
|
|
|
free_reserved_area((void *)vaddr, (void *)(vaddr + size), -1, NULL);
|
2012-02-16 01:14:45 +00:00
|
|
|
}
|
|
|
|
|
2019-09-11 14:46:52 +00:00
|
|
|
s32 fadump_setup_cpu_notes_buf(u32 num_cpus)
|
2019-09-11 14:46:36 +00:00
|
|
|
{
|
|
|
|
/* Allocate buffer to hold cpu crash notes. */
|
|
|
|
fw_dump.cpu_notes_buf_size = num_cpus * sizeof(note_buf_t);
|
|
|
|
fw_dump.cpu_notes_buf_size = PAGE_ALIGN(fw_dump.cpu_notes_buf_size);
|
|
|
|
fw_dump.cpu_notes_buf_vaddr =
|
|
|
|
(unsigned long)fadump_alloc_buffer(fw_dump.cpu_notes_buf_size);
|
|
|
|
if (!fw_dump.cpu_notes_buf_vaddr) {
|
|
|
|
pr_err("Failed to allocate %ld bytes for CPU notes buffer\n",
|
|
|
|
fw_dump.cpu_notes_buf_size);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("Allocated buffer for cpu notes of size %ld at 0x%lx\n",
|
|
|
|
fw_dump.cpu_notes_buf_size,
|
|
|
|
fw_dump.cpu_notes_buf_vaddr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-09-11 14:46:52 +00:00
|
|
|
void fadump_free_cpu_notes_buf(void)
|
2019-09-11 14:46:36 +00:00
|
|
|
{
|
|
|
|
if (!fw_dump.cpu_notes_buf_vaddr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
fadump_free_buffer(fw_dump.cpu_notes_buf_vaddr,
|
|
|
|
fw_dump.cpu_notes_buf_size);
|
|
|
|
fw_dump.cpu_notes_buf_vaddr = 0;
|
|
|
|
fw_dump.cpu_notes_buf_size = 0;
|
|
|
|
}
|
|
|
|
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
static void free_crash_memory_ranges(void)
|
|
|
|
{
|
|
|
|
kfree(crash_memory_ranges);
|
|
|
|
crash_memory_ranges = NULL;
|
|
|
|
crash_memory_ranges_size = 0;
|
|
|
|
max_crash_mem_ranges = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate or reallocate crash memory ranges array in incremental units
|
|
|
|
* of PAGE_SIZE.
|
|
|
|
*/
|
|
|
|
static int allocate_crash_memory_ranges(void)
|
|
|
|
{
|
|
|
|
struct fad_crash_memory_ranges *new_array;
|
|
|
|
u64 new_size;
|
|
|
|
|
|
|
|
new_size = crash_memory_ranges_size + PAGE_SIZE;
|
|
|
|
pr_debug("Allocating %llu bytes of memory for crash memory ranges\n",
|
|
|
|
new_size);
|
|
|
|
|
|
|
|
new_array = krealloc(crash_memory_ranges, new_size, GFP_KERNEL);
|
|
|
|
if (new_array == NULL) {
|
|
|
|
pr_err("Insufficient memory for setting up crash memory ranges\n");
|
|
|
|
free_crash_memory_ranges();
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
crash_memory_ranges = new_array;
|
|
|
|
crash_memory_ranges_size = new_size;
|
|
|
|
max_crash_mem_ranges = (new_size /
|
|
|
|
sizeof(struct fad_crash_memory_ranges));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int fadump_add_crash_memory(unsigned long long base,
|
|
|
|
unsigned long long end)
|
2012-02-16 01:14:37 +00:00
|
|
|
{
|
2018-08-06 20:42:54 +00:00
|
|
|
u64 start, size;
|
|
|
|
bool is_adjacent = false;
|
|
|
|
|
2012-02-16 01:14:37 +00:00
|
|
|
if (base == end)
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
return 0;
|
|
|
|
|
2018-08-06 20:42:54 +00:00
|
|
|
/*
|
|
|
|
* Fold adjacent memory ranges to bring down the memory ranges/
|
|
|
|
* PT_LOAD segments count.
|
|
|
|
*/
|
|
|
|
if (crash_mem_ranges) {
|
|
|
|
start = crash_memory_ranges[crash_mem_ranges - 1].base;
|
|
|
|
size = crash_memory_ranges[crash_mem_ranges - 1].size;
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
|
2018-08-06 20:42:54 +00:00
|
|
|
if ((start + size) == base)
|
|
|
|
is_adjacent = true;
|
|
|
|
}
|
|
|
|
if (!is_adjacent) {
|
|
|
|
/* resize the array on reaching the limit */
|
|
|
|
if (crash_mem_ranges == max_crash_mem_ranges) {
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = allocate_crash_memory_ranges();
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
start = base;
|
|
|
|
crash_memory_ranges[crash_mem_ranges].base = start;
|
|
|
|
crash_mem_ranges++;
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
}
|
2012-02-16 01:14:37 +00:00
|
|
|
|
2018-08-06 20:42:54 +00:00
|
|
|
crash_memory_ranges[crash_mem_ranges - 1].size = (end - start);
|
2012-02-16 01:14:37 +00:00
|
|
|
pr_debug("crash_memory_range[%d] [%#016llx-%#016llx], %#llx bytes\n",
|
2018-08-06 20:42:54 +00:00
|
|
|
(crash_mem_ranges - 1), start, end - 1, (end - start));
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
return 0;
|
2012-02-16 01:14:37 +00:00
|
|
|
}
|
|
|
|
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
static int fadump_exclude_reserved_area(unsigned long long start,
|
2012-02-16 01:14:37 +00:00
|
|
|
unsigned long long end)
|
|
|
|
{
|
|
|
|
unsigned long long ra_start, ra_end;
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
int ret = 0;
|
2012-02-16 01:14:37 +00:00
|
|
|
|
|
|
|
ra_start = fw_dump.reserve_dump_area_start;
|
|
|
|
ra_end = ra_start + fw_dump.reserve_dump_area_size;
|
|
|
|
|
|
|
|
if ((ra_start < end) && (ra_end > start)) {
|
|
|
|
if ((start < ra_start) && (end > ra_end)) {
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
ret = fadump_add_crash_memory(start, ra_start);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = fadump_add_crash_memory(ra_end, end);
|
2012-02-16 01:14:37 +00:00
|
|
|
} else if (start < ra_start) {
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
ret = fadump_add_crash_memory(start, ra_start);
|
2012-02-16 01:14:37 +00:00
|
|
|
} else if (ra_end < end) {
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
ret = fadump_add_crash_memory(ra_end, end);
|
2012-02-16 01:14:37 +00:00
|
|
|
}
|
|
|
|
} else
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
ret = fadump_add_crash_memory(start, end);
|
|
|
|
|
|
|
|
return ret;
|
2012-02-16 01:14:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int fadump_init_elfcore_header(char *bufp)
|
|
|
|
{
|
|
|
|
struct elfhdr *elf;
|
|
|
|
|
|
|
|
elf = (struct elfhdr *) bufp;
|
|
|
|
bufp += sizeof(struct elfhdr);
|
|
|
|
memcpy(elf->e_ident, ELFMAG, SELFMAG);
|
|
|
|
elf->e_ident[EI_CLASS] = ELF_CLASS;
|
|
|
|
elf->e_ident[EI_DATA] = ELF_DATA;
|
|
|
|
elf->e_ident[EI_VERSION] = EV_CURRENT;
|
|
|
|
elf->e_ident[EI_OSABI] = ELF_OSABI;
|
|
|
|
memset(elf->e_ident+EI_PAD, 0, EI_NIDENT-EI_PAD);
|
|
|
|
elf->e_type = ET_CORE;
|
|
|
|
elf->e_machine = ELF_ARCH;
|
|
|
|
elf->e_version = EV_CURRENT;
|
|
|
|
elf->e_entry = 0;
|
|
|
|
elf->e_phoff = sizeof(struct elfhdr);
|
|
|
|
elf->e_shoff = 0;
|
2016-09-06 05:32:42 +00:00
|
|
|
#if defined(_CALL_ELF)
|
|
|
|
elf->e_flags = _CALL_ELF;
|
|
|
|
#else
|
|
|
|
elf->e_flags = 0;
|
|
|
|
#endif
|
2012-02-16 01:14:37 +00:00
|
|
|
elf->e_ehsize = sizeof(struct elfhdr);
|
|
|
|
elf->e_phentsize = sizeof(struct elf_phdr);
|
|
|
|
elf->e_phnum = 0;
|
|
|
|
elf->e_shentsize = 0;
|
|
|
|
elf->e_shnum = 0;
|
|
|
|
elf->e_shstrndx = 0;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Traverse through memblock structure and setup crash memory ranges. These
|
|
|
|
* ranges will be used create PT_LOAD program headers in elfcore header.
|
|
|
|
*/
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
static int fadump_setup_crash_memory_ranges(void)
|
2012-02-16 01:14:37 +00:00
|
|
|
{
|
|
|
|
struct memblock_region *reg;
|
|
|
|
unsigned long long start, end;
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
int ret;
|
2012-02-16 01:14:37 +00:00
|
|
|
|
|
|
|
pr_debug("Setup crash memory ranges.\n");
|
|
|
|
crash_mem_ranges = 0;
|
2018-08-06 20:42:54 +00:00
|
|
|
|
2012-02-16 01:14:37 +00:00
|
|
|
/*
|
|
|
|
* add the first memory chunk (RMA_START through boot_memory_size) as
|
|
|
|
* a separate memory chunk. The reason is, at the time crash firmware
|
|
|
|
* will move the content of this memory chunk to different location
|
|
|
|
* specified during fadump registration. We need to create a separate
|
|
|
|
* program header for this chunk with the correct offset.
|
|
|
|
*/
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
ret = fadump_add_crash_memory(RMA_START, fw_dump.boot_memory_size);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-02-16 01:14:37 +00:00
|
|
|
|
|
|
|
for_each_memblock(memory, reg) {
|
|
|
|
start = (unsigned long long)reg->base;
|
|
|
|
end = start + (unsigned long long)reg->size;
|
2017-06-01 17:20:38 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* skip the first memory chunk that is already added (RMA_START
|
|
|
|
* through boot_memory_size). This logic needs a relook if and
|
|
|
|
* when RMA_START changes to a non-zero value.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(RMA_START != 0);
|
|
|
|
if (start < fw_dump.boot_memory_size) {
|
|
|
|
if (end > fw_dump.boot_memory_size)
|
|
|
|
start = fw_dump.boot_memory_size;
|
|
|
|
else
|
|
|
|
continue;
|
|
|
|
}
|
2012-02-16 01:14:37 +00:00
|
|
|
|
|
|
|
/* add this range excluding the reserved dump area. */
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
ret = fadump_exclude_reserved_area(start, end);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-02-16 01:14:37 +00:00
|
|
|
}
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
|
|
|
|
return 0;
|
2012-02-16 01:14:37 +00:00
|
|
|
}
|
|
|
|
|
2012-02-16 01:14:53 +00:00
|
|
|
/*
|
|
|
|
* If the given physical address falls within the boot memory region then
|
|
|
|
* return the relocated address that points to the dump region reserved
|
|
|
|
* for saving initial boot memory contents.
|
|
|
|
*/
|
|
|
|
static inline unsigned long fadump_relocate(unsigned long paddr)
|
|
|
|
{
|
|
|
|
if (paddr > RMA_START && paddr < fw_dump.boot_memory_size)
|
2019-09-11 14:48:57 +00:00
|
|
|
return fw_dump.boot_mem_dest_addr + paddr;
|
2012-02-16 01:14:53 +00:00
|
|
|
else
|
|
|
|
return paddr;
|
|
|
|
}
|
|
|
|
|
2012-02-16 01:14:37 +00:00
|
|
|
static int fadump_create_elfcore_headers(char *bufp)
|
|
|
|
{
|
|
|
|
struct elfhdr *elf;
|
|
|
|
struct elf_phdr *phdr;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
fadump_init_elfcore_header(bufp);
|
|
|
|
elf = (struct elfhdr *)bufp;
|
|
|
|
bufp += sizeof(struct elfhdr);
|
|
|
|
|
2012-02-16 01:14:45 +00:00
|
|
|
/*
|
|
|
|
* setup ELF PT_NOTE, place holder for cpu notes info. The notes info
|
|
|
|
* will be populated during second kernel boot after crash. Hence
|
|
|
|
* this PT_NOTE will always be the first elf note.
|
|
|
|
*
|
|
|
|
* NOTE: Any new ELF note addition should be placed after this note.
|
|
|
|
*/
|
|
|
|
phdr = (struct elf_phdr *)bufp;
|
|
|
|
bufp += sizeof(struct elf_phdr);
|
|
|
|
phdr->p_type = PT_NOTE;
|
|
|
|
phdr->p_flags = 0;
|
|
|
|
phdr->p_vaddr = 0;
|
|
|
|
phdr->p_align = 0;
|
|
|
|
|
|
|
|
phdr->p_offset = 0;
|
|
|
|
phdr->p_paddr = 0;
|
|
|
|
phdr->p_filesz = 0;
|
|
|
|
phdr->p_memsz = 0;
|
|
|
|
|
|
|
|
(elf->e_phnum)++;
|
|
|
|
|
2012-02-16 01:14:53 +00:00
|
|
|
/* setup ELF PT_NOTE for vmcoreinfo */
|
|
|
|
phdr = (struct elf_phdr *)bufp;
|
|
|
|
bufp += sizeof(struct elf_phdr);
|
|
|
|
phdr->p_type = PT_NOTE;
|
|
|
|
phdr->p_flags = 0;
|
|
|
|
phdr->p_vaddr = 0;
|
|
|
|
phdr->p_align = 0;
|
|
|
|
|
|
|
|
phdr->p_paddr = fadump_relocate(paddr_vmcoreinfo_note());
|
|
|
|
phdr->p_offset = phdr->p_paddr;
|
2017-07-12 21:33:17 +00:00
|
|
|
phdr->p_memsz = phdr->p_filesz = VMCOREINFO_NOTE_SIZE;
|
2012-02-16 01:14:53 +00:00
|
|
|
|
|
|
|
/* Increment number of program headers. */
|
|
|
|
(elf->e_phnum)++;
|
|
|
|
|
2012-02-16 01:14:37 +00:00
|
|
|
/* setup PT_LOAD sections. */
|
|
|
|
|
|
|
|
for (i = 0; i < crash_mem_ranges; i++) {
|
|
|
|
unsigned long long mbase, msize;
|
|
|
|
mbase = crash_memory_ranges[i].base;
|
|
|
|
msize = crash_memory_ranges[i].size;
|
|
|
|
|
|
|
|
if (!msize)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
phdr = (struct elf_phdr *)bufp;
|
|
|
|
bufp += sizeof(struct elf_phdr);
|
|
|
|
phdr->p_type = PT_LOAD;
|
|
|
|
phdr->p_flags = PF_R|PF_W|PF_X;
|
|
|
|
phdr->p_offset = mbase;
|
|
|
|
|
|
|
|
if (mbase == RMA_START) {
|
|
|
|
/*
|
|
|
|
* The entire RMA region will be moved by firmware
|
|
|
|
* to the specified destination_address. Hence set
|
|
|
|
* the correct offset.
|
|
|
|
*/
|
2019-09-11 14:48:57 +00:00
|
|
|
phdr->p_offset = fw_dump.boot_mem_dest_addr;
|
2012-02-16 01:14:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
phdr->p_paddr = mbase;
|
|
|
|
phdr->p_vaddr = (unsigned long)__va(mbase);
|
|
|
|
phdr->p_filesz = msize;
|
|
|
|
phdr->p_memsz = msize;
|
|
|
|
phdr->p_align = 0;
|
|
|
|
|
|
|
|
/* Increment number of program headers. */
|
|
|
|
(elf->e_phnum)++;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long init_fadump_header(unsigned long addr)
|
|
|
|
{
|
|
|
|
struct fadump_crash_info_header *fdh;
|
|
|
|
|
|
|
|
if (!addr)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
fdh = __va(addr);
|
|
|
|
addr += sizeof(struct fadump_crash_info_header);
|
|
|
|
|
|
|
|
memset(fdh, 0, sizeof(struct fadump_crash_info_header));
|
|
|
|
fdh->magic_number = FADUMP_CRASH_INFO_MAGIC;
|
|
|
|
fdh->elfcorehdr_addr = addr;
|
2012-02-16 01:14:45 +00:00
|
|
|
/* We will set the crashing cpu id in crash_fadump() during crash. */
|
2019-09-11 14:48:14 +00:00
|
|
|
fdh->crashing_cpu = FADUMP_CPU_UNKNOWN;
|
2012-02-16 01:14:37 +00:00
|
|
|
|
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
|
2017-05-27 15:46:15 +00:00
|
|
|
static int register_fadump(void)
|
2012-02-20 02:15:03 +00:00
|
|
|
{
|
2012-02-16 01:14:37 +00:00
|
|
|
unsigned long addr;
|
|
|
|
void *vaddr;
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
int ret;
|
2012-02-16 01:14:37 +00:00
|
|
|
|
2012-02-20 02:15:03 +00:00
|
|
|
/*
|
|
|
|
* If no memory is reserved then we can not register for firmware-
|
|
|
|
* assisted dump.
|
|
|
|
*/
|
|
|
|
if (!fw_dump.reserve_dump_area_size)
|
2017-05-27 15:46:15 +00:00
|
|
|
return -ENODEV;
|
2012-02-20 02:15:03 +00:00
|
|
|
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
ret = fadump_setup_crash_memory_ranges();
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-02-16 01:14:37 +00:00
|
|
|
|
2019-09-11 14:48:57 +00:00
|
|
|
addr = fw_dump.fadumphdr_addr;
|
|
|
|
|
2012-02-16 01:14:37 +00:00
|
|
|
/* Initialize fadump crash info header. */
|
|
|
|
addr = init_fadump_header(addr);
|
|
|
|
vaddr = __va(addr);
|
|
|
|
|
|
|
|
pr_debug("Creating ELF core headers at %#016lx\n", addr);
|
|
|
|
fadump_create_elfcore_headers(vaddr);
|
|
|
|
|
2012-02-20 02:15:03 +00:00
|
|
|
/* register the future kernel dump with firmware. */
|
2019-09-11 14:48:57 +00:00
|
|
|
pr_debug("Registering for firmware-assisted kernel dump...\n");
|
|
|
|
return fw_dump.ops->fadump_register(&fw_dump);
|
2012-02-20 02:15:03 +00:00
|
|
|
}
|
|
|
|
|
2012-02-16 01:15:08 +00:00
|
|
|
void fadump_cleanup(void)
|
|
|
|
{
|
2019-09-11 14:51:16 +00:00
|
|
|
if (!fw_dump.fadump_supported)
|
|
|
|
return;
|
|
|
|
|
2012-02-16 01:15:08 +00:00
|
|
|
/* Invalidate the registration only if dump is active. */
|
|
|
|
if (fw_dump.dump_active) {
|
2019-09-11 14:49:44 +00:00
|
|
|
pr_debug("Invalidating firmware-assisted dump registration\n");
|
|
|
|
fw_dump.ops->fadump_invalidate(&fw_dump);
|
2018-04-27 06:23:18 +00:00
|
|
|
} else if (fw_dump.dump_registered) {
|
|
|
|
/* Un-register Firmware-assisted dump if it was registered. */
|
2019-09-11 14:48:57 +00:00
|
|
|
fw_dump.ops->fadump_unregister(&fw_dump);
|
powerpc/fadump: handle crash memory ranges array index overflow
Crash memory ranges is an array of memory ranges of the crashing kernel
to be exported as a dump via /proc/vmcore file. The size of the array
is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
commit 142b45a72e22 ("memblock: Add array resizing support").
On large memory systems with a few DLPAR operations, the memblock memory
regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
systems, registering fadump results in crash or other system failures
like below:
task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160
Call Trace:
resched_curr+0x138/0x160 (unreliable)
check_preempt_curr+0xc8/0xf0
ttwu_do_wakeup+0x38/0x150
try_to_wake_up+0x224/0x4d0
__wake_up_common+0x94/0x100
ep_poll_callback+0xac/0x1c0
__wake_up_common+0x94/0x100
__wake_up_sync_key+0x70/0xa0
sock_def_readable+0x58/0xa0
unix_stream_sendmsg+0x2dc/0x4c0
sock_sendmsg+0x68/0xa0
___sys_sendmsg+0x2cc/0x2e0
__sys_sendmsg+0x5c/0xc0
SyS_socketcall+0x36c/0x3f0
system_call+0x3c/0x100
as array index overflow is not checked for while setting up crash memory
ranges causing memory corruption. To resolve this issue, dynamically
allocate memory for crash memory ranges and resize it incrementally,
in units of pagesize, on hitting array size limit.
Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 20:42:45 +00:00
|
|
|
free_crash_memory_ranges();
|
2012-02-16 01:15:08 +00:00
|
|
|
}
|
2019-09-11 14:51:16 +00:00
|
|
|
|
|
|
|
if (fw_dump.ops->fadump_cleanup)
|
|
|
|
fw_dump.ops->fadump_cleanup(&fw_dump);
|
2012-02-16 01:15:08 +00:00
|
|
|
}
|
|
|
|
|
2017-06-01 19:40:10 +00:00
|
|
|
static void fadump_free_reserved_memory(unsigned long start_pfn,
|
|
|
|
unsigned long end_pfn)
|
|
|
|
{
|
|
|
|
unsigned long pfn;
|
|
|
|
unsigned long time_limit = jiffies + HZ;
|
|
|
|
|
|
|
|
pr_info("freeing reserved memory (0x%llx - 0x%llx)\n",
|
|
|
|
PFN_PHYS(start_pfn), PFN_PHYS(end_pfn));
|
|
|
|
|
|
|
|
for (pfn = start_pfn; pfn < end_pfn; pfn++) {
|
|
|
|
free_reserved_page(pfn_to_page(pfn));
|
|
|
|
|
|
|
|
if (time_after(jiffies, time_limit)) {
|
|
|
|
cond_resched();
|
|
|
|
time_limit = jiffies + HZ;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip memory holes and free memory that was actually reserved.
|
|
|
|
*/
|
|
|
|
static void fadump_release_reserved_area(unsigned long start, unsigned long end)
|
|
|
|
{
|
|
|
|
struct memblock_region *reg;
|
|
|
|
unsigned long tstart, tend;
|
|
|
|
unsigned long start_pfn = PHYS_PFN(start);
|
|
|
|
unsigned long end_pfn = PHYS_PFN(end);
|
|
|
|
|
|
|
|
for_each_memblock(memory, reg) {
|
|
|
|
tstart = max(start_pfn, memblock_region_memory_base_pfn(reg));
|
|
|
|
tend = min(end_pfn, memblock_region_memory_end_pfn(reg));
|
|
|
|
if (tstart < tend) {
|
|
|
|
fadump_free_reserved_memory(tstart, tend);
|
|
|
|
|
|
|
|
if (tend == end_pfn)
|
|
|
|
break;
|
|
|
|
|
|
|
|
start_pfn = tend + 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-02-16 01:15:08 +00:00
|
|
|
/*
|
|
|
|
* Release the memory that was reserved in early boot to preserve the memory
|
|
|
|
* contents. The released memory will be available for general use.
|
|
|
|
*/
|
|
|
|
static void fadump_release_memory(unsigned long begin, unsigned long end)
|
|
|
|
{
|
|
|
|
unsigned long ra_start, ra_end;
|
|
|
|
|
|
|
|
ra_start = fw_dump.reserve_dump_area_start;
|
|
|
|
ra_end = ra_start + fw_dump.reserve_dump_area_size;
|
|
|
|
|
2017-06-01 19:40:10 +00:00
|
|
|
/*
|
|
|
|
* exclude the dump reserve area. Will reuse it for next
|
|
|
|
* fadump registration.
|
|
|
|
*/
|
|
|
|
if (begin < ra_end && end > ra_start) {
|
|
|
|
if (begin < ra_start)
|
|
|
|
fadump_release_reserved_area(begin, ra_start);
|
|
|
|
if (end > ra_end)
|
|
|
|
fadump_release_reserved_area(ra_end, end);
|
|
|
|
} else
|
|
|
|
fadump_release_reserved_area(begin, end);
|
2012-02-16 01:15:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void fadump_invalidate_release_mem(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&fadump_mutex);
|
|
|
|
if (!fw_dump.dump_active) {
|
|
|
|
mutex_unlock(&fadump_mutex);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
fadump_cleanup();
|
|
|
|
mutex_unlock(&fadump_mutex);
|
|
|
|
|
2019-09-11 14:49:28 +00:00
|
|
|
fadump_release_memory(fw_dump.boot_memory_size, memblock_end_of_DRAM());
|
2019-09-11 14:46:36 +00:00
|
|
|
fadump_free_cpu_notes_buf();
|
|
|
|
|
2012-02-16 01:15:08 +00:00
|
|
|
/* Initialize the kernel dump memory structure for FAD registration. */
|
2019-09-11 14:48:57 +00:00
|
|
|
fw_dump.ops->fadump_init_mem_struct(&fw_dump);
|
2012-02-16 01:15:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t fadump_release_memory_store(struct kobject *kobj,
|
|
|
|
struct kobj_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
2017-06-26 14:06:01 +00:00
|
|
|
int input = -1;
|
|
|
|
|
2012-02-16 01:15:08 +00:00
|
|
|
if (!fw_dump.dump_active)
|
|
|
|
return -EPERM;
|
|
|
|
|
2017-06-26 14:06:01 +00:00
|
|
|
if (kstrtoint(buf, 0, &input))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (input == 1) {
|
2012-02-16 01:15:08 +00:00
|
|
|
/*
|
|
|
|
* Take away the '/proc/vmcore'. We are releasing the dump
|
|
|
|
* memory, hence it will not be valid anymore.
|
|
|
|
*/
|
2016-09-30 00:51:46 +00:00
|
|
|
#ifdef CONFIG_PROC_VMCORE
|
2012-02-16 01:15:08 +00:00
|
|
|
vmcore_cleanup();
|
2016-09-30 00:51:46 +00:00
|
|
|
#endif
|
2012-02-16 01:15:08 +00:00
|
|
|
fadump_invalidate_release_mem();
|
|
|
|
|
|
|
|
} else
|
|
|
|
return -EINVAL;
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2012-02-20 02:15:03 +00:00
|
|
|
static ssize_t fadump_enabled_show(struct kobject *kobj,
|
|
|
|
struct kobj_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t fadump_register_show(struct kobject *kobj,
|
|
|
|
struct kobj_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
return sprintf(buf, "%d\n", fw_dump.dump_registered);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t fadump_register_store(struct kobject *kobj,
|
|
|
|
struct kobj_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
2017-06-26 14:06:01 +00:00
|
|
|
int input = -1;
|
2012-02-20 02:15:03 +00:00
|
|
|
|
2019-09-11 14:49:44 +00:00
|
|
|
if (!fw_dump.fadump_enabled || fw_dump.dump_active)
|
2012-02-20 02:15:03 +00:00
|
|
|
return -EPERM;
|
|
|
|
|
2017-06-26 14:06:01 +00:00
|
|
|
if (kstrtoint(buf, 0, &input))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-02-20 02:15:03 +00:00
|
|
|
mutex_lock(&fadump_mutex);
|
|
|
|
|
2017-06-26 14:06:01 +00:00
|
|
|
switch (input) {
|
|
|
|
case 0:
|
2012-02-20 02:15:03 +00:00
|
|
|
if (fw_dump.dump_registered == 0) {
|
|
|
|
goto unlock_out;
|
|
|
|
}
|
2019-09-11 14:49:44 +00:00
|
|
|
|
2012-02-20 02:15:03 +00:00
|
|
|
/* Un-register Firmware-assisted dump */
|
2019-09-11 14:48:57 +00:00
|
|
|
pr_debug("Un-register firmware-assisted dump\n");
|
|
|
|
fw_dump.ops->fadump_unregister(&fw_dump);
|
2012-02-20 02:15:03 +00:00
|
|
|
break;
|
2017-06-26 14:06:01 +00:00
|
|
|
case 1:
|
2012-02-20 02:15:03 +00:00
|
|
|
if (fw_dump.dump_registered == 1) {
|
2018-09-14 14:06:02 +00:00
|
|
|
/* Un-register Firmware-assisted dump */
|
2019-09-11 14:48:57 +00:00
|
|
|
fw_dump.ops->fadump_unregister(&fw_dump);
|
2012-02-20 02:15:03 +00:00
|
|
|
}
|
|
|
|
/* Register Firmware-assisted dump */
|
2017-05-27 15:46:15 +00:00
|
|
|
ret = register_fadump();
|
2012-02-20 02:15:03 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
unlock_out:
|
|
|
|
mutex_unlock(&fadump_mutex);
|
|
|
|
return ret < 0 ? ret : count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int fadump_region_show(struct seq_file *m, void *private)
|
|
|
|
{
|
|
|
|
if (!fw_dump.fadump_enabled)
|
|
|
|
return 0;
|
|
|
|
|
2012-02-16 01:15:08 +00:00
|
|
|
mutex_lock(&fadump_mutex);
|
2019-09-11 14:49:44 +00:00
|
|
|
fw_dump.ops->fadump_region_show(&fw_dump, m);
|
|
|
|
mutex_unlock(&fadump_mutex);
|
2012-02-20 02:15:03 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-02-16 01:15:08 +00:00
|
|
|
static struct kobj_attribute fadump_release_attr = __ATTR(fadump_release_mem,
|
|
|
|
0200, NULL,
|
|
|
|
fadump_release_memory_store);
|
2012-02-20 02:15:03 +00:00
|
|
|
static struct kobj_attribute fadump_attr = __ATTR(fadump_enabled,
|
|
|
|
0444, fadump_enabled_show,
|
|
|
|
NULL);
|
|
|
|
static struct kobj_attribute fadump_register_attr = __ATTR(fadump_registered,
|
|
|
|
0644, fadump_register_show,
|
|
|
|
fadump_register_store);
|
|
|
|
|
2018-11-05 15:01:19 +00:00
|
|
|
DEFINE_SHOW_ATTRIBUTE(fadump_region);
|
2012-02-20 02:15:03 +00:00
|
|
|
|
|
|
|
static void fadump_init_files(void)
|
|
|
|
{
|
|
|
|
struct dentry *debugfs_file;
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
rc = sysfs_create_file(kernel_kobj, &fadump_attr.attr);
|
|
|
|
if (rc)
|
|
|
|
printk(KERN_ERR "fadump: unable to create sysfs file"
|
|
|
|
" fadump_enabled (%d)\n", rc);
|
|
|
|
|
|
|
|
rc = sysfs_create_file(kernel_kobj, &fadump_register_attr.attr);
|
|
|
|
if (rc)
|
|
|
|
printk(KERN_ERR "fadump: unable to create sysfs file"
|
|
|
|
" fadump_registered (%d)\n", rc);
|
|
|
|
|
|
|
|
debugfs_file = debugfs_create_file("fadump_region", 0444,
|
|
|
|
powerpc_debugfs_root, NULL,
|
|
|
|
&fadump_region_fops);
|
|
|
|
if (!debugfs_file)
|
|
|
|
printk(KERN_ERR "fadump: unable to create debugfs file"
|
|
|
|
" fadump_region\n");
|
2012-02-16 01:15:08 +00:00
|
|
|
|
|
|
|
if (fw_dump.dump_active) {
|
|
|
|
rc = sysfs_create_file(kernel_kobj, &fadump_release_attr.attr);
|
|
|
|
if (rc)
|
|
|
|
printk(KERN_ERR "fadump: unable to create sysfs file"
|
|
|
|
" fadump_release_mem (%d)\n", rc);
|
|
|
|
}
|
2012-02-20 02:15:03 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepare for firmware-assisted dump.
|
|
|
|
*/
|
|
|
|
int __init setup_fadump(void)
|
|
|
|
{
|
|
|
|
if (!fw_dump.fadump_enabled)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!fw_dump.fadump_supported) {
|
|
|
|
printk(KERN_ERR "Firmware-assisted dump is not supported on"
|
|
|
|
" this hardware\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
fadump_show_config();
|
2012-02-16 01:14:37 +00:00
|
|
|
/*
|
|
|
|
* If dump data is available then see if it is valid and prepare for
|
|
|
|
* saving it to the disk.
|
|
|
|
*/
|
2012-02-16 01:15:08 +00:00
|
|
|
if (fw_dump.dump_active) {
|
|
|
|
/*
|
|
|
|
* if dump process fails then invalidate the registration
|
|
|
|
* and release memory before proceeding for re-registration.
|
|
|
|
*/
|
2019-09-11 14:49:44 +00:00
|
|
|
if (fw_dump.ops->fadump_process(&fw_dump) < 0)
|
2012-02-16 01:15:08 +00:00
|
|
|
fadump_invalidate_release_mem();
|
|
|
|
}
|
2012-02-20 02:15:03 +00:00
|
|
|
/* Initialize the kernel dump memory structure for FAD registration. */
|
2012-02-16 01:14:37 +00:00
|
|
|
else if (fw_dump.reserve_dump_area_size)
|
2019-09-11 14:48:57 +00:00
|
|
|
fw_dump.ops->fadump_init_mem_struct(&fw_dump);
|
2019-09-11 14:49:44 +00:00
|
|
|
|
2012-02-20 02:15:03 +00:00
|
|
|
fadump_init_files();
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
subsys_initcall(setup_fadump);
|