2019-05-27 14:55:05 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2012-02-16 09:14:22 +08: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 10:15:03 +08:00
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/seq_file.h>
|
2012-02-16 09:14:37 +08:00
|
|
|
#include <linux/crash_dump.h>
|
2012-02-16 09:15:08 +08:00
|
|
|
#include <linux/kobject.h>
|
|
|
|
#include <linux/sysfs.h>
|
2018-08-18 04:40:56 +08: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 16:17:17 +08:00
|
|
|
#include <linux/cma.h>
|
2019-04-26 13:59:47 +08:00
|
|
|
#include <linux/hugetlb.h>
|
2021-08-12 21:28:31 +08:00
|
|
|
#include <linux/debugfs.h>
|
2012-02-16 09:14:22 +08:00
|
|
|
|
|
|
|
#include <asm/page.h>
|
|
|
|
#include <asm/prom.h>
|
|
|
|
#include <asm/fadump.h>
|
2019-09-11 22:46:21 +08:00
|
|
|
#include <asm/fadump-internal.h>
|
2012-03-30 22:01:07 +08:00
|
|
|
#include <asm/setup.h>
|
2021-04-19 20:24:32 +08:00
|
|
|
#include <asm/interrupt.h>
|
2012-02-16 09:14:22 +08:00
|
|
|
|
2020-07-13 13:24:35 +08:00
|
|
|
/*
|
|
|
|
* The CPU who acquired the lock to trigger the fadump crash should
|
|
|
|
* wait for other CPUs to enter.
|
|
|
|
*
|
|
|
|
* The timeout is in milliseconds.
|
|
|
|
*/
|
|
|
|
#define CRASH_TIMEOUT 500
|
|
|
|
|
2012-02-16 09:14:22 +08:00
|
|
|
static struct fw_dump fw_dump;
|
2012-02-20 10:15:03 +08:00
|
|
|
|
2019-09-11 22:55:49 +08:00
|
|
|
static void __init fadump_reserve_crash_area(u64 base);
|
|
|
|
|
2019-09-11 22:56:03 +08:00
|
|
|
#ifndef CONFIG_PRESERVE_FA_DUMP
|
2020-07-27 11:44:36 +08:00
|
|
|
|
2021-04-21 20:54:01 +08:00
|
|
|
static struct kobject *fadump_kobj;
|
|
|
|
|
2020-07-27 11:44:36 +08:00
|
|
|
static atomic_t cpus_in_fadump;
|
2012-02-20 10:15:03 +08:00
|
|
|
static DEFINE_MUTEX(fadump_mutex);
|
2020-07-27 11:44:36 +08:00
|
|
|
|
2021-04-21 20:54:01 +08:00
|
|
|
static struct fadump_mrange_info crash_mrange_info = { "crash", NULL, 0, 0, 0, false };
|
2020-04-20 16:56:09 +08:00
|
|
|
|
|
|
|
#define RESERVED_RNGS_SZ 16384 /* 16K - 128 entries */
|
|
|
|
#define RESERVED_RNGS_CNT (RESERVED_RNGS_SZ / \
|
|
|
|
sizeof(struct fadump_memory_range))
|
|
|
|
static struct fadump_memory_range rngs[RESERVED_RNGS_CNT];
|
2021-04-21 20:54:01 +08:00
|
|
|
static struct fadump_mrange_info
|
|
|
|
reserved_mrange_info = { "reserved", rngs, RESERVED_RNGS_SZ, 0, RESERVED_RNGS_CNT, true };
|
2020-04-20 16:56:09 +08:00
|
|
|
|
|
|
|
static void __init early_init_dt_scan_reserved_ranges(unsigned long node);
|
2012-02-16 09:14:22 +08: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 16:17:17 +08:00
|
|
|
#ifdef CONFIG_CMA
|
2019-09-11 22:48:14 +08: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 16:17:17 +08: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.
|
|
|
|
*/
|
2021-04-21 20:54:01 +08:00
|
|
|
static int __init fadump_cma_init(void)
|
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 16:17:17 +08:00
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2022-03-23 05:46:17 +08:00
|
|
|
/*
|
|
|
|
* If CMA activation fails, keep the pages reserved, instead of
|
|
|
|
* exposing them to buddy allocator. Same as 'fadump=nocma' case.
|
|
|
|
*/
|
|
|
|
cma_reserve_pages_on_error(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 16:17:17 +08:00
|
|
|
/*
|
|
|
|
* 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 09:14:22 +08:00
|
|
|
/* Scan the Firmware Assisted dump configuration details. */
|
2019-09-11 22:49:44 +08:00
|
|
|
int __init early_init_dt_scan_fw_dump(unsigned long node, const char *uname,
|
|
|
|
int depth, void *data)
|
2012-02-16 09:14:22 +08:00
|
|
|
{
|
2020-04-20 16:56:09 +08:00
|
|
|
if (depth == 0) {
|
|
|
|
early_init_dt_scan_reserved_ranges(node);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:50:26 +08:00
|
|
|
if (depth != 1)
|
2012-02-16 09:14:22 +08:00
|
|
|
return 0;
|
|
|
|
|
2019-09-11 22:50:26 +08: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 09:14:22 +08:00
|
|
|
}
|
|
|
|
|
2017-06-02 01:21:26 +08:00
|
|
|
/*
|
|
|
|
* If fadump is registered, check if the memory provided
|
2018-08-20 16:17:32 +08:00
|
|
|
* falls within boot memory area and reserved memory area.
|
2017-06-02 01:21:26 +08:00
|
|
|
*/
|
2019-09-11 22:57:26 +08:00
|
|
|
int is_fadump_memory_area(u64 addr, unsigned long size)
|
2017-06-02 01:21:26 +08:00
|
|
|
{
|
2019-09-11 22:57:26 +08:00
|
|
|
u64 d_start, d_end;
|
2018-08-20 16:17:32 +08:00
|
|
|
|
2017-06-02 01:21:26 +08:00
|
|
|
if (!fw_dump.dump_registered)
|
|
|
|
return 0;
|
|
|
|
|
2019-09-11 22:57:26 +08:00
|
|
|
if (!size)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
d_start = fw_dump.reserve_dump_area_start;
|
|
|
|
d_end = d_start + fw_dump.reserve_dump_area_size;
|
2018-08-20 16:17:32 +08:00
|
|
|
if (((addr + size) > d_start) && (addr <= d_end))
|
|
|
|
return 1;
|
|
|
|
|
2019-09-11 22:57:39 +08:00
|
|
|
return (addr <= fw_dump.boot_mem_top);
|
2017-06-02 01:21:26 +08: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 14:59:11 +08:00
|
|
|
int should_fadump_crash(void)
|
|
|
|
{
|
|
|
|
if (!fw_dump.dump_registered || !fw_dump.fadumphdr_addr)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2012-02-20 10:15:03 +08:00
|
|
|
int is_fadump_active(void)
|
|
|
|
{
|
|
|
|
return fw_dump.dump_active;
|
|
|
|
}
|
|
|
|
|
2017-06-02 01:22:10 +08:00
|
|
|
/*
|
2019-09-11 22:46:36 +08:00
|
|
|
* Returns true, if there are no holes in memory area between d_start to d_end,
|
|
|
|
* false otherwise.
|
2017-06-02 01:22:10 +08:00
|
|
|
*/
|
2019-09-11 22:46:36 +08:00
|
|
|
static bool is_fadump_mem_area_contiguous(u64 d_start, u64 d_end)
|
2017-06-02 01:22:10 +08:00
|
|
|
{
|
2020-10-14 07:58:08 +08:00
|
|
|
phys_addr_t reg_start, reg_end;
|
2019-09-11 22:46:36 +08:00
|
|
|
bool ret = false;
|
2020-10-14 07:58:08 +08:00
|
|
|
u64 i, start, end;
|
2017-06-02 01:22:10 +08:00
|
|
|
|
2020-10-14 07:58:08 +08:00
|
|
|
for_each_mem_range(i, ®_start, ®_end) {
|
|
|
|
start = max_t(u64, d_start, reg_start);
|
|
|
|
end = min_t(u64, d_end, reg_end);
|
2019-09-11 22:46:36 +08:00
|
|
|
if (d_start < end) {
|
|
|
|
/* Memory hole from d_start to start */
|
|
|
|
if (start > d_start)
|
2017-06-02 01:22:10 +08:00
|
|
|
break;
|
|
|
|
|
2019-09-11 22:46:36 +08:00
|
|
|
if (end == d_end) {
|
|
|
|
ret = true;
|
2017-06-02 01:22:10 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:46:36 +08:00
|
|
|
d_start = end + 1;
|
2017-06-02 01:22:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:46:36 +08:00
|
|
|
/*
|
|
|
|
* Returns true, if there are no holes in boot memory area,
|
|
|
|
* false otherwise.
|
|
|
|
*/
|
2019-09-11 22:46:52 +08:00
|
|
|
bool is_fadump_boot_mem_contiguous(void)
|
2019-09-11 22:46:36 +08:00
|
|
|
{
|
2019-09-11 22:57:39 +08:00
|
|
|
unsigned long d_start, d_end;
|
|
|
|
bool ret = false;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < fw_dump.boot_mem_regs_cnt; i++) {
|
|
|
|
d_start = fw_dump.boot_mem_addr[i];
|
|
|
|
d_end = d_start + fw_dump.boot_mem_sz[i];
|
|
|
|
|
|
|
|
ret = is_fadump_mem_area_contiguous(d_start, d_end);
|
|
|
|
if (!ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
2019-09-11 22:46:36 +08:00
|
|
|
}
|
|
|
|
|
2018-08-20 16:17:24 +08:00
|
|
|
/*
|
|
|
|
* Returns true, if there are no holes in reserved memory area,
|
|
|
|
* false otherwise.
|
|
|
|
*/
|
2019-09-11 22:46:52 +08:00
|
|
|
bool is_fadump_reserved_mem_contiguous(void)
|
2018-08-20 16:17:24 +08:00
|
|
|
{
|
2019-09-11 22:46:36 +08:00
|
|
|
u64 d_start, d_end;
|
2018-08-20 16:17:24 +08:00
|
|
|
|
2019-09-11 22:46:36 +08: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 16:17:24 +08:00
|
|
|
}
|
|
|
|
|
2012-02-20 10:15:03 +08:00
|
|
|
/* Print firmware assisted dump configurations for debugging purpose. */
|
2021-12-17 06:00:16 +08:00
|
|
|
static void __init fadump_show_config(void)
|
2012-02-20 10:15:03 +08:00
|
|
|
{
|
2019-09-11 22:57:39 +08:00
|
|
|
int i;
|
|
|
|
|
2012-02-20 10:15:03 +08:00
|
|
|
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);
|
2019-09-11 22:57:39 +08:00
|
|
|
pr_debug(" Boot memory size : %lx\n", fw_dump.boot_memory_size);
|
|
|
|
pr_debug(" Boot memory top : %llx\n", fw_dump.boot_mem_top);
|
|
|
|
pr_debug("Boot memory regions cnt: %llx\n", fw_dump.boot_mem_regs_cnt);
|
|
|
|
for (i = 0; i < fw_dump.boot_mem_regs_cnt; i++) {
|
|
|
|
pr_debug("[%03d] base = %llx, size = %llx\n", i,
|
|
|
|
fw_dump.boot_mem_addr[i], fw_dump.boot_mem_sz[i]);
|
|
|
|
}
|
2012-02-20 10:15:03 +08:00
|
|
|
}
|
|
|
|
|
2012-02-16 09:14:22 +08: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.
|
|
|
|
*
|
|
|
|
*/
|
2021-03-03 03:50:14 +08:00
|
|
|
static __init u64 fadump_calculate_reserve_size(void)
|
2012-02-16 09:14:22 +08:00
|
|
|
{
|
2019-09-11 22:56:59 +08:00
|
|
|
u64 base, size, bootmem_min;
|
2017-05-09 06:56:28 +08:00
|
|
|
int ret;
|
2012-02-16 09:14:22 +08:00
|
|
|
|
2017-05-22 17:34:23 +08:00
|
|
|
if (fw_dump.reserve_bootvar)
|
|
|
|
pr_warn("'fadump_reserve_mem=' parameter is deprecated in favor of 'crashkernel=' parameter.\n");
|
|
|
|
|
2012-02-16 09:14:22 +08:00
|
|
|
/*
|
2017-05-09 06:56:28 +08:00
|
|
|
* Check if the size is specified through crashkernel= cmdline
|
2017-05-22 17:34:47 +08:00
|
|
|
* option. If yes, then use that but ignore base as fadump reserves
|
|
|
|
* memory at a predefined offset.
|
2012-02-16 09:14:22 +08:00
|
|
|
*/
|
2017-05-09 06:56:28 +08: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 15:30:27 +08:00
|
|
|
unsigned long max_size;
|
|
|
|
|
2017-05-22 17:34:23 +08:00
|
|
|
if (fw_dump.reserve_bootvar)
|
|
|
|
pr_info("Using 'crashkernel=' parameter for memory reservation.\n");
|
|
|
|
|
2017-05-09 06:56:28 +08: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 15:30:27 +08: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 09:14:22 +08:00
|
|
|
return fw_dump.reserve_bootvar;
|
2017-05-22 17:34:23 +08: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-09 06:56:28 +08:00
|
|
|
}
|
2012-02-16 09:14:22 +08: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 15:30:27 +08:00
|
|
|
size = memblock_phys_mem_size() / 20;
|
2012-02-16 09:14:22 +08: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;
|
|
|
|
|
2019-09-11 22:56:59 +08:00
|
|
|
bootmem_min = fw_dump.ops->fadump_get_bootmem_min();
|
|
|
|
return (size > bootmem_min ? size : bootmem_min);
|
2012-02-16 09:14:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the total memory size required to be reserved for
|
|
|
|
* firmware-assisted dump registration.
|
|
|
|
*/
|
2021-12-17 06:00:16 +08:00
|
|
|
static unsigned long __init get_fadump_area_size(void)
|
2012-02-16 09:14:22 +08:00
|
|
|
{
|
|
|
|
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 09:14:37 +08:00
|
|
|
size += sizeof(struct fadump_crash_info_header);
|
|
|
|
size += sizeof(struct elfhdr); /* ELF core header.*/
|
2012-02-16 09:14:45 +08:00
|
|
|
size += sizeof(struct elf_phdr); /* place holder for cpu notes */
|
2012-02-16 09:14:37 +08:00
|
|
|
/* Program headers for crash memory regions. */
|
|
|
|
size += sizeof(struct elf_phdr) * (memblock_num_regions(memory) + 2);
|
2012-02-16 09:14:22 +08:00
|
|
|
|
|
|
|
size = PAGE_ALIGN(size);
|
2019-09-11 22:50:57 +08: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 09:14:22 +08:00
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:57:39 +08:00
|
|
|
static int __init add_boot_mem_region(unsigned long rstart,
|
|
|
|
unsigned long rsize)
|
|
|
|
{
|
|
|
|
int i = fw_dump.boot_mem_regs_cnt++;
|
|
|
|
|
|
|
|
if (fw_dump.boot_mem_regs_cnt > FADUMP_MAX_MEM_REGS) {
|
|
|
|
fw_dump.boot_mem_regs_cnt = FADUMP_MAX_MEM_REGS;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("Added boot memory range[%d] [%#016lx-%#016lx)\n",
|
|
|
|
i, rstart, (rstart + rsize));
|
|
|
|
fw_dump.boot_mem_addr[i] = rstart;
|
|
|
|
fw_dump.boot_mem_sz[i] = rsize;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Firmware usually has a hard limit on the data it can copy per region.
|
|
|
|
* Honour that by splitting a memory range into multiple regions.
|
|
|
|
*/
|
|
|
|
static int __init add_boot_mem_regions(unsigned long mstart,
|
|
|
|
unsigned long msize)
|
|
|
|
{
|
|
|
|
unsigned long rstart, rsize, max_size;
|
|
|
|
int ret = 1;
|
|
|
|
|
|
|
|
rstart = mstart;
|
|
|
|
max_size = fw_dump.max_copy_size ? fw_dump.max_copy_size : msize;
|
|
|
|
while (msize) {
|
|
|
|
if (msize > max_size)
|
|
|
|
rsize = max_size;
|
|
|
|
else
|
|
|
|
rsize = msize;
|
|
|
|
|
|
|
|
ret = add_boot_mem_region(rstart, rsize);
|
|
|
|
if (!ret)
|
|
|
|
break;
|
|
|
|
|
|
|
|
msize -= rsize;
|
|
|
|
rstart += rsize;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __init fadump_get_boot_mem_regions(void)
|
|
|
|
{
|
2020-10-14 07:58:08 +08:00
|
|
|
unsigned long size, cur_size, hole_size, last_end;
|
2019-09-11 22:57:39 +08:00
|
|
|
unsigned long mem_size = fw_dump.boot_memory_size;
|
2020-10-14 07:58:08 +08:00
|
|
|
phys_addr_t reg_start, reg_end;
|
2019-09-11 22:57:39 +08:00
|
|
|
int ret = 1;
|
2020-10-14 07:58:08 +08:00
|
|
|
u64 i;
|
2019-09-11 22:57:39 +08:00
|
|
|
|
|
|
|
fw_dump.boot_mem_regs_cnt = 0;
|
|
|
|
|
|
|
|
last_end = 0;
|
|
|
|
hole_size = 0;
|
|
|
|
cur_size = 0;
|
2020-10-14 07:58:08 +08:00
|
|
|
for_each_mem_range(i, ®_start, ®_end) {
|
|
|
|
size = reg_end - reg_start;
|
|
|
|
hole_size += (reg_start - last_end);
|
2019-09-11 22:57:39 +08:00
|
|
|
|
|
|
|
if ((cur_size + size) >= mem_size) {
|
|
|
|
size = (mem_size - cur_size);
|
2020-10-14 07:58:08 +08:00
|
|
|
ret = add_boot_mem_regions(reg_start, size);
|
2019-09-11 22:57:39 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
mem_size -= size;
|
|
|
|
cur_size += size;
|
2020-10-14 07:58:08 +08:00
|
|
|
ret = add_boot_mem_regions(reg_start, size);
|
2019-09-11 22:57:39 +08:00
|
|
|
if (!ret)
|
|
|
|
break;
|
|
|
|
|
2020-10-14 07:58:08 +08:00
|
|
|
last_end = reg_end;
|
2019-09-11 22:57:39 +08:00
|
|
|
}
|
|
|
|
fw_dump.boot_mem_top = PAGE_ALIGN(fw_dump.boot_memory_size + hole_size);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-04-20 16:56:22 +08:00
|
|
|
/*
|
|
|
|
* Returns true, if the given range overlaps with reserved memory ranges
|
|
|
|
* starting at idx. Also, updates idx to index of overlapping memory range
|
|
|
|
* with the given memory range.
|
|
|
|
* False, otherwise.
|
|
|
|
*/
|
2021-12-17 06:00:16 +08:00
|
|
|
static bool __init overlaps_reserved_ranges(u64 base, u64 end, int *idx)
|
2020-04-20 16:56:22 +08:00
|
|
|
{
|
|
|
|
bool ret = false;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = *idx; i < reserved_mrange_info.mem_range_cnt; i++) {
|
|
|
|
u64 rbase = reserved_mrange_info.mem_ranges[i].base;
|
|
|
|
u64 rend = rbase + reserved_mrange_info.mem_ranges[i].size;
|
|
|
|
|
|
|
|
if (end <= rbase)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if ((end > rbase) && (base < rend)) {
|
|
|
|
*idx = i;
|
|
|
|
ret = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Locate a suitable memory area to reserve memory for FADump. While at it,
|
|
|
|
* lookup reserved-ranges & avoid overlap with them, as they are used by F/W.
|
|
|
|
*/
|
|
|
|
static u64 __init fadump_locate_reserve_mem(u64 base, u64 size)
|
|
|
|
{
|
|
|
|
struct fadump_memory_range *mrngs;
|
|
|
|
phys_addr_t mstart, mend;
|
|
|
|
int idx = 0;
|
|
|
|
u64 i, ret = 0;
|
|
|
|
|
|
|
|
mrngs = reserved_mrange_info.mem_ranges;
|
|
|
|
for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
|
|
|
|
&mstart, &mend, NULL) {
|
|
|
|
pr_debug("%llu) mstart: %llx, mend: %llx, base: %llx\n",
|
|
|
|
i, mstart, mend, base);
|
|
|
|
|
|
|
|
if (mstart > base)
|
|
|
|
base = PAGE_ALIGN(mstart);
|
|
|
|
|
|
|
|
while ((mend > base) && ((mend - base) >= size)) {
|
|
|
|
if (!overlaps_reserved_ranges(base, base+size, &idx)) {
|
|
|
|
ret = base;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
base = mrngs[idx].base + mrngs[idx].size;
|
|
|
|
base = PAGE_ALIGN(base);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-02-16 09:14:22 +08:00
|
|
|
int __init fadump_reserve_mem(void)
|
|
|
|
{
|
2020-04-20 16:56:22 +08:00
|
|
|
u64 base, size, mem_boundary, bootmem_min;
|
2019-09-11 22:50:41 +08:00
|
|
|
int ret = 1;
|
2012-02-16 09:14:22 +08:00
|
|
|
|
|
|
|
if (!fw_dump.fadump_enabled)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!fw_dump.fadump_supported) {
|
2019-09-11 22:50:41 +08:00
|
|
|
pr_info("Firmware-Assisted Dump is not supported on this hardware\n");
|
|
|
|
goto error_out;
|
2012-02-16 09:14:22 +08:00
|
|
|
}
|
2019-09-11 22:50:57 +08:00
|
|
|
|
2012-02-20 10:15:03 +08:00
|
|
|
/*
|
|
|
|
* Initialize boot memory size
|
|
|
|
* If dump is active then we have already calculated the size during
|
|
|
|
* first kernel.
|
|
|
|
*/
|
2019-09-11 22:49:44 +08:00
|
|
|
if (!fw_dump.dump_active) {
|
2019-09-11 22:50:41 +08: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 16:17:17 +08:00
|
|
|
#ifdef CONFIG_CMA
|
2019-09-11 22:54:28 +08:00
|
|
|
if (!fw_dump.nocma) {
|
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 16:17:17 +08:00
|
|
|
fw_dump.boot_memory_size =
|
2020-04-20 16:56:22 +08:00
|
|
|
ALIGN(fw_dump.boot_memory_size,
|
2022-03-23 05:43:17 +08:00
|
|
|
CMA_MIN_ALIGNMENT_BYTES);
|
2019-09-11 22:54:28 +08: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 16:17:17 +08:00
|
|
|
#endif
|
2019-09-11 22:56:59 +08:00
|
|
|
|
|
|
|
bootmem_min = fw_dump.ops->fadump_get_bootmem_min();
|
|
|
|
if (fw_dump.boot_memory_size < bootmem_min) {
|
|
|
|
pr_err("Can't enable fadump with boot memory size (0x%lx) less than 0x%llx\n",
|
|
|
|
fw_dump.boot_memory_size, bootmem_min);
|
|
|
|
goto error_out;
|
|
|
|
}
|
2019-09-11 22:57:39 +08:00
|
|
|
|
|
|
|
if (!fadump_get_boot_mem_regions()) {
|
|
|
|
pr_err("Too many holes in boot memory area to enable fadump\n");
|
|
|
|
goto error_out;
|
|
|
|
}
|
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 16:17:17 +08:00
|
|
|
}
|
2012-02-16 09:14:22 +08: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 09:42:33 +08:00
|
|
|
" dump, now %#016llx\n", memory_limit);
|
2012-02-16 09:14:22 +08:00
|
|
|
}
|
|
|
|
if (memory_limit)
|
2019-09-11 22:50:41 +08:00
|
|
|
mem_boundary = memory_limit;
|
2012-02-16 09:14:22 +08:00
|
|
|
else
|
2019-09-11 22:50:41 +08:00
|
|
|
mem_boundary = memblock_end_of_DRAM();
|
2012-02-16 09:14:22 +08:00
|
|
|
|
2019-09-11 22:57:39 +08:00
|
|
|
base = fw_dump.boot_mem_top;
|
2019-09-11 22:49:28 +08:00
|
|
|
size = get_fadump_area_size();
|
|
|
|
fw_dump.reserve_dump_area_size = size;
|
2012-02-16 09:14:22 +08:00
|
|
|
if (fw_dump.dump_active) {
|
2018-04-10 21:41:16 +08:00
|
|
|
pr_info("Firmware-assisted dump is active.\n");
|
|
|
|
|
2018-04-10 21:41:31 +08: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 09:14:22 +08:00
|
|
|
/*
|
|
|
|
* If last boot has crashed then reserve all the memory
|
2019-09-11 22:55:49 +08:00
|
|
|
* above boot memory size so that we don't touch it until
|
2012-02-16 09:14:22 +08:00
|
|
|
* dump is written to disk by userspace tool. This memory
|
2019-09-11 22:55:49 +08:00
|
|
|
* can be released for general use by invalidating fadump.
|
2012-02-16 09:14:22 +08:00
|
|
|
*/
|
2019-09-11 22:55:49 +08:00
|
|
|
fadump_reserve_crash_area(base);
|
2012-02-16 09:14:37 +08:00
|
|
|
|
2019-09-11 22:49:44 +08: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 22:49:28 +08:00
|
|
|
} else {
|
2017-03-17 05:05:26 +08:00
|
|
|
/*
|
|
|
|
* Reserve memory at an offset closer to bottom of the RAM to
|
2019-09-11 22:54:28 +08:00
|
|
|
* minimize the impact of memory hot-remove operation.
|
2017-03-17 05:05:26 +08:00
|
|
|
*/
|
2020-04-20 16:56:22 +08:00
|
|
|
base = fadump_locate_reserve_mem(base, size);
|
2019-09-11 22:50:41 +08:00
|
|
|
|
2020-05-27 17:44:35 +08:00
|
|
|
if (!base || (base + size > mem_boundary)) {
|
2019-09-11 22:50:57 +08:00
|
|
|
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 22:50:41 +08:00
|
|
|
pr_err("Failed to reserve memory!\n");
|
|
|
|
goto error_out;
|
2017-03-17 05:05:26 +08:00
|
|
|
}
|
|
|
|
|
2019-09-11 22:50:41 +08:00
|
|
|
pr_info("Reserved %lldMB of memory at %#016llx (System RAM: %lldMB)\n",
|
|
|
|
(size >> 20), base, (memblock_phys_mem_size() >> 20));
|
2017-03-17 05:05:26 +08:00
|
|
|
|
2019-09-11 22:50:41 +08: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 16:17:17 +08:00
|
|
|
}
|
2019-09-11 22:50:41 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
error_out:
|
|
|
|
fw_dump.fadump_enabled = 0;
|
|
|
|
return 0;
|
2012-02-16 09:14:22 +08: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 16:17:17 +08:00
|
|
|
else if (strncmp(p, "nocma", 5) == 0) {
|
|
|
|
fw_dump.fadump_enabled = 1;
|
|
|
|
fw_dump.nocma = 1;
|
|
|
|
}
|
2012-02-16 09:14:22 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("fadump", early_fadump_param);
|
|
|
|
|
2017-05-22 17:34:23 +08: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 09:14:45 +08:00
|
|
|
void crash_fadump(struct pt_regs *regs, const char *str)
|
|
|
|
{
|
2020-07-13 13:24:35 +08:00
|
|
|
unsigned int msecs;
|
2012-02-16 09:14:45 +08:00
|
|
|
struct fadump_crash_info_header *fdh = NULL;
|
2016-10-25 02:21:51 +08:00
|
|
|
int old_cpu, this_cpu;
|
2020-07-13 13:24:35 +08:00
|
|
|
/* Do not include first CPU */
|
|
|
|
unsigned int ncpus = num_online_cpus() - 1;
|
2012-02-16 09:14:45 +08: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 14:59:11 +08:00
|
|
|
if (!should_fadump_crash())
|
2012-02-16 09:14:45 +08:00
|
|
|
return;
|
|
|
|
|
2016-10-25 02:21:51 +08: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) {
|
2020-07-13 13:24:35 +08:00
|
|
|
atomic_inc(&cpus_in_fadump);
|
|
|
|
|
2016-10-25 02:21:51 +08:00
|
|
|
/*
|
|
|
|
* 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 09:14:45 +08: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-21 07:00:13 +08:00
|
|
|
fdh->online_mask = *cpu_online_mask;
|
2012-02-16 09:14:45 +08:00
|
|
|
|
2020-07-13 13:24:35 +08:00
|
|
|
/*
|
|
|
|
* If we came in via system reset, wait a while for the secondary
|
|
|
|
* CPUs to enter.
|
|
|
|
*/
|
2021-04-14 19:00:33 +08:00
|
|
|
if (TRAP(&(fdh->regs)) == INTERRUPT_SYSTEM_RESET) {
|
2020-07-13 13:24:35 +08:00
|
|
|
msecs = CRASH_TIMEOUT;
|
|
|
|
while ((atomic_read(&cpus_in_fadump) < ncpus) && (--msecs > 0))
|
|
|
|
mdelay(1);
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:48:57 +08:00
|
|
|
fw_dump.ops->fadump_trigger(fdh, str);
|
2012-02-16 09:14:45 +08:00
|
|
|
}
|
|
|
|
|
2021-12-17 06:00:16 +08:00
|
|
|
u32 *__init fadump_regs_to_elf_notes(u32 *buf, struct pt_regs *regs)
|
2012-02-16 09:14:45 +08: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-09 06:56:24 +08:00
|
|
|
buf = append_elf_note(buf, CRASH_CORE_NOTE_NAME, NT_PRSTATUS,
|
|
|
|
&prstatus, sizeof(prstatus));
|
2012-02-16 09:14:45 +08:00
|
|
|
return buf;
|
|
|
|
}
|
|
|
|
|
2021-12-17 06:00:16 +08:00
|
|
|
void __init fadump_update_elfcore_header(char *bufp)
|
2012-02-16 09:14:45 +08:00
|
|
|
{
|
|
|
|
struct elf_phdr *phdr;
|
|
|
|
|
|
|
|
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 22:46:36 +08:00
|
|
|
phdr->p_paddr = __pa(fw_dump.cpu_notes_buf_vaddr);
|
2012-02-16 09:14:45 +08: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;
|
|
|
|
}
|
|
|
|
|
2021-12-17 06:00:16 +08:00
|
|
|
static void *__init fadump_alloc_buffer(unsigned long size)
|
2012-02-16 09:14:45 +08:00
|
|
|
{
|
2019-09-11 22:47:56 +08:00
|
|
|
unsigned long count, i;
|
2012-02-16 09:14:45 +08:00
|
|
|
struct page *page;
|
2019-09-11 22:47:56 +08:00
|
|
|
void *vaddr;
|
2012-02-16 09:14:45 +08:00
|
|
|
|
2019-09-11 22:47:56 +08:00
|
|
|
vaddr = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO);
|
2012-02-16 09:14:45 +08:00
|
|
|
if (!vaddr)
|
|
|
|
return NULL;
|
|
|
|
|
2019-09-11 22:47:56 +08:00
|
|
|
count = PAGE_ALIGN(size) / PAGE_SIZE;
|
2012-02-16 09:14:45 +08:00
|
|
|
page = virt_to_page(vaddr);
|
|
|
|
for (i = 0; i < count; i++)
|
2019-09-11 22:47:56 +08:00
|
|
|
mark_page_reserved(page + i);
|
2012-02-16 09:14:45 +08:00
|
|
|
return vaddr;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:46:36 +08:00
|
|
|
static void fadump_free_buffer(unsigned long vaddr, unsigned long size)
|
2012-02-16 09:14:45 +08:00
|
|
|
{
|
2019-09-11 22:47:56 +08:00
|
|
|
free_reserved_area((void *)vaddr, (void *)(vaddr + size), -1, NULL);
|
2012-02-16 09:14:45 +08:00
|
|
|
}
|
|
|
|
|
2021-12-17 06:00:16 +08:00
|
|
|
s32 __init fadump_setup_cpu_notes_buf(u32 num_cpus)
|
2019-09-11 22:46:36 +08: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 22:46:52 +08:00
|
|
|
void fadump_free_cpu_notes_buf(void)
|
2019-09-11 22:46:36 +08: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;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
static void fadump_free_mem_ranges(struct fadump_mrange_info *mrange_info)
|
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-07 04:42:45 +08:00
|
|
|
{
|
2020-04-20 16:56:09 +08:00
|
|
|
if (mrange_info->is_static) {
|
|
|
|
mrange_info->mem_range_cnt = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
kfree(mrange_info->mem_ranges);
|
2020-04-20 16:56:09 +08:00
|
|
|
memset((void *)((u64)mrange_info + RNG_NAME_SZ), 0,
|
|
|
|
(sizeof(struct fadump_mrange_info) - RNG_NAME_SZ));
|
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-07 04:42:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2019-09-11 22:55:05 +08:00
|
|
|
* Allocate or reallocate mem_ranges array in incremental units
|
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-07 04:42:45 +08:00
|
|
|
* of PAGE_SIZE.
|
|
|
|
*/
|
2019-09-11 22:55:05 +08:00
|
|
|
static int fadump_alloc_mem_ranges(struct fadump_mrange_info *mrange_info)
|
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-07 04:42:45 +08:00
|
|
|
{
|
2019-09-11 22:55:05 +08:00
|
|
|
struct fadump_memory_range *new_array;
|
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-07 04:42:45 +08:00
|
|
|
u64 new_size;
|
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
new_size = mrange_info->mem_ranges_sz + PAGE_SIZE;
|
|
|
|
pr_debug("Allocating %llu bytes of memory for %s memory ranges\n",
|
|
|
|
new_size, mrange_info->name);
|
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-07 04:42:45 +08:00
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
new_array = krealloc(mrange_info->mem_ranges, new_size, GFP_KERNEL);
|
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-07 04:42:45 +08:00
|
|
|
if (new_array == NULL) {
|
2019-09-11 22:55:05 +08:00
|
|
|
pr_err("Insufficient memory for setting up %s memory ranges\n",
|
|
|
|
mrange_info->name);
|
|
|
|
fadump_free_mem_ranges(mrange_info);
|
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-07 04:42:45 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
mrange_info->mem_ranges = new_array;
|
|
|
|
mrange_info->mem_ranges_sz = new_size;
|
|
|
|
mrange_info->max_mem_ranges = (new_size /
|
|
|
|
sizeof(struct fadump_memory_range));
|
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-07 04:42:45 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
static inline int fadump_add_mem_range(struct fadump_mrange_info *mrange_info,
|
|
|
|
u64 base, u64 end)
|
2012-02-16 09:14:37 +08:00
|
|
|
{
|
2019-09-11 22:55:05 +08:00
|
|
|
struct fadump_memory_range *mem_ranges = mrange_info->mem_ranges;
|
2018-08-07 04:42:54 +08:00
|
|
|
bool is_adjacent = false;
|
2019-09-11 22:55:05 +08:00
|
|
|
u64 start, size;
|
2018-08-07 04:42:54 +08:00
|
|
|
|
2012-02-16 09:14:37 +08: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-07 04:42:45 +08:00
|
|
|
return 0;
|
|
|
|
|
2018-08-07 04:42:54 +08:00
|
|
|
/*
|
|
|
|
* Fold adjacent memory ranges to bring down the memory ranges/
|
|
|
|
* PT_LOAD segments count.
|
|
|
|
*/
|
2019-09-11 22:55:05 +08:00
|
|
|
if (mrange_info->mem_range_cnt) {
|
|
|
|
start = mem_ranges[mrange_info->mem_range_cnt - 1].base;
|
|
|
|
size = mem_ranges[mrange_info->mem_range_cnt - 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-07 04:42:45 +08:00
|
|
|
|
2018-08-07 04:42:54 +08:00
|
|
|
if ((start + size) == base)
|
|
|
|
is_adjacent = true;
|
|
|
|
}
|
|
|
|
if (!is_adjacent) {
|
|
|
|
/* resize the array on reaching the limit */
|
2019-09-11 22:55:05 +08:00
|
|
|
if (mrange_info->mem_range_cnt == mrange_info->max_mem_ranges) {
|
2018-08-07 04:42:54 +08:00
|
|
|
int ret;
|
|
|
|
|
2020-04-20 16:56:09 +08:00
|
|
|
if (mrange_info->is_static) {
|
|
|
|
pr_err("Reached array size limit for %s memory ranges\n",
|
|
|
|
mrange_info->name);
|
|
|
|
return -ENOSPC;
|
|
|
|
}
|
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
ret = fadump_alloc_mem_ranges(mrange_info);
|
2018-08-07 04:42:54 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2019-09-11 22:55:05 +08:00
|
|
|
|
|
|
|
/* Update to the new resized array */
|
|
|
|
mem_ranges = mrange_info->mem_ranges;
|
2018-08-07 04:42:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
start = base;
|
2019-09-11 22:55:05 +08:00
|
|
|
mem_ranges[mrange_info->mem_range_cnt].base = start;
|
|
|
|
mrange_info->mem_range_cnt++;
|
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-07 04:42:45 +08:00
|
|
|
}
|
2012-02-16 09:14:37 +08:00
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
mem_ranges[mrange_info->mem_range_cnt - 1].size = (end - start);
|
|
|
|
pr_debug("%s_memory_range[%d] [%#016llx-%#016llx], %#llx bytes\n",
|
|
|
|
mrange_info->name, (mrange_info->mem_range_cnt - 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-07 04:42:45 +08:00
|
|
|
return 0;
|
2012-02-16 09:14:37 +08:00
|
|
|
}
|
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
static int fadump_exclude_reserved_area(u64 start, u64 end)
|
2012-02-16 09:14:37 +08:00
|
|
|
{
|
2019-09-11 22:55:05 +08:00
|
|
|
u64 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-07 04:42:45 +08:00
|
|
|
int ret = 0;
|
2012-02-16 09:14:37 +08: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)) {
|
2019-09-11 22:55:05 +08:00
|
|
|
ret = fadump_add_mem_range(&crash_mrange_info,
|
|
|
|
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-07 04:42:45 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
ret = fadump_add_mem_range(&crash_mrange_info,
|
|
|
|
ra_end, end);
|
2012-02-16 09:14:37 +08:00
|
|
|
} else if (start < ra_start) {
|
2019-09-11 22:55:05 +08:00
|
|
|
ret = fadump_add_mem_range(&crash_mrange_info,
|
|
|
|
start, ra_start);
|
2012-02-16 09:14:37 +08:00
|
|
|
} else if (ra_end < end) {
|
2019-09-11 22:55:05 +08:00
|
|
|
ret = fadump_add_mem_range(&crash_mrange_info,
|
|
|
|
ra_end, end);
|
2012-02-16 09:14:37 +08:00
|
|
|
}
|
|
|
|
} else
|
2019-09-11 22:55:05 +08:00
|
|
|
ret = fadump_add_mem_range(&crash_mrange_info, 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-07 04:42:45 +08:00
|
|
|
|
|
|
|
return ret;
|
2012-02-16 09:14:37 +08: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 13:32:42 +08:00
|
|
|
#if defined(_CALL_ELF)
|
|
|
|
elf->e_flags = _CALL_ELF;
|
|
|
|
#else
|
|
|
|
elf->e_flags = 0;
|
|
|
|
#endif
|
2012-02-16 09:14:37 +08: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-07 04:42:45 +08:00
|
|
|
static int fadump_setup_crash_memory_ranges(void)
|
2012-02-16 09:14:37 +08:00
|
|
|
{
|
2020-10-14 07:58:08 +08:00
|
|
|
u64 i, start, end;
|
|
|
|
int ret;
|
2012-02-16 09:14:37 +08:00
|
|
|
|
|
|
|
pr_debug("Setup crash memory ranges.\n");
|
2019-09-11 22:55:05 +08:00
|
|
|
crash_mrange_info.mem_range_cnt = 0;
|
2018-08-07 04:42:54 +08:00
|
|
|
|
2012-02-16 09:14:37 +08:00
|
|
|
/*
|
2019-09-11 22:57:39 +08:00
|
|
|
* Boot memory region(s) registered with firmware are moved to
|
|
|
|
* different location at the time of crash. Create separate program
|
|
|
|
* header(s) for this memory chunk(s) with the correct offset.
|
2012-02-16 09:14:37 +08:00
|
|
|
*/
|
2019-09-11 22:57:39 +08:00
|
|
|
for (i = 0; i < fw_dump.boot_mem_regs_cnt; i++) {
|
|
|
|
start = fw_dump.boot_mem_addr[i];
|
|
|
|
end = start + fw_dump.boot_mem_sz[i];
|
|
|
|
ret = fadump_add_mem_range(&crash_mrange_info, start, end);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2012-02-16 09:14:37 +08:00
|
|
|
|
2020-10-14 07:58:08 +08:00
|
|
|
for_each_mem_range(i, &start, &end) {
|
2017-06-02 01:20:38 +08:00
|
|
|
/*
|
2019-09-11 22:57:39 +08:00
|
|
|
* skip the memory chunk that is already added
|
|
|
|
* (0 through boot_memory_top).
|
2017-06-02 01:20:38 +08:00
|
|
|
*/
|
2019-09-11 22:57:39 +08:00
|
|
|
if (start < fw_dump.boot_mem_top) {
|
|
|
|
if (end > fw_dump.boot_mem_top)
|
|
|
|
start = fw_dump.boot_mem_top;
|
2017-06-02 01:20:38 +08:00
|
|
|
else
|
|
|
|
continue;
|
|
|
|
}
|
2012-02-16 09:14:37 +08: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-07 04:42:45 +08:00
|
|
|
ret = fadump_exclude_reserved_area(start, end);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-02-16 09:14:37 +08: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-07 04:42:45 +08:00
|
|
|
|
|
|
|
return 0;
|
2012-02-16 09:14:37 +08:00
|
|
|
}
|
|
|
|
|
2012-02-16 09:14:53 +08: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)
|
|
|
|
{
|
2019-09-11 22:57:39 +08:00
|
|
|
unsigned long raddr, rstart, rend, rlast, hole_size;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
hole_size = 0;
|
|
|
|
rlast = 0;
|
|
|
|
raddr = paddr;
|
|
|
|
for (i = 0; i < fw_dump.boot_mem_regs_cnt; i++) {
|
|
|
|
rstart = fw_dump.boot_mem_addr[i];
|
|
|
|
rend = rstart + fw_dump.boot_mem_sz[i];
|
|
|
|
hole_size += (rstart - rlast);
|
|
|
|
|
|
|
|
if (paddr >= rstart && paddr < rend) {
|
|
|
|
raddr += fw_dump.boot_mem_dest_addr - hole_size;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
rlast = rend;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("vmcoreinfo: paddr = 0x%lx, raddr = 0x%lx\n", paddr, raddr);
|
|
|
|
return raddr;
|
2012-02-16 09:14:53 +08:00
|
|
|
}
|
|
|
|
|
2012-02-16 09:14:37 +08:00
|
|
|
static int fadump_create_elfcore_headers(char *bufp)
|
|
|
|
{
|
2019-09-11 22:57:39 +08:00
|
|
|
unsigned long long raddr, offset;
|
2012-02-16 09:14:37 +08:00
|
|
|
struct elf_phdr *phdr;
|
2019-09-11 22:57:39 +08:00
|
|
|
struct elfhdr *elf;
|
|
|
|
int i, j;
|
2012-02-16 09:14:37 +08:00
|
|
|
|
|
|
|
fadump_init_elfcore_header(bufp);
|
|
|
|
elf = (struct elfhdr *)bufp;
|
|
|
|
bufp += sizeof(struct elfhdr);
|
|
|
|
|
2012-02-16 09:14:45 +08: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 09:14:53 +08: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-13 05:33:17 +08:00
|
|
|
phdr->p_memsz = phdr->p_filesz = VMCOREINFO_NOTE_SIZE;
|
2012-02-16 09:14:53 +08:00
|
|
|
|
|
|
|
/* Increment number of program headers. */
|
|
|
|
(elf->e_phnum)++;
|
|
|
|
|
2012-02-16 09:14:37 +08:00
|
|
|
/* setup PT_LOAD sections. */
|
2019-09-11 22:57:39 +08:00
|
|
|
j = 0;
|
|
|
|
offset = 0;
|
|
|
|
raddr = fw_dump.boot_mem_addr[0];
|
2019-09-11 22:55:05 +08:00
|
|
|
for (i = 0; i < crash_mrange_info.mem_range_cnt; i++) {
|
|
|
|
u64 mbase, msize;
|
2012-02-16 09:14:37 +08:00
|
|
|
|
2019-09-11 22:55:05 +08:00
|
|
|
mbase = crash_mrange_info.mem_ranges[i].base;
|
|
|
|
msize = crash_mrange_info.mem_ranges[i].size;
|
2012-02-16 09:14:37 +08:00
|
|
|
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;
|
|
|
|
|
2019-09-11 22:57:39 +08:00
|
|
|
if (mbase == raddr) {
|
2012-02-16 09:14:37 +08:00
|
|
|
/*
|
2019-09-11 22:57:26 +08:00
|
|
|
* The entire real memory region will be moved by
|
|
|
|
* firmware to the specified destination_address.
|
|
|
|
* Hence set the correct offset.
|
2012-02-16 09:14:37 +08:00
|
|
|
*/
|
2019-09-11 22:57:39 +08:00
|
|
|
phdr->p_offset = fw_dump.boot_mem_dest_addr + offset;
|
|
|
|
if (j < (fw_dump.boot_mem_regs_cnt - 1)) {
|
|
|
|
offset += fw_dump.boot_mem_sz[j];
|
|
|
|
raddr = fw_dump.boot_mem_addr[++j];
|
|
|
|
}
|
2012-02-16 09:14:37 +08: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 09:14:45 +08:00
|
|
|
/* We will set the crashing cpu id in crash_fadump() during crash. */
|
2019-09-11 22:48:14 +08:00
|
|
|
fdh->crashing_cpu = FADUMP_CPU_UNKNOWN;
|
2012-02-16 09:14:37 +08:00
|
|
|
|
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
|
2017-05-27 23:46:15 +08:00
|
|
|
static int register_fadump(void)
|
2012-02-20 10:15:03 +08:00
|
|
|
{
|
2012-02-16 09:14:37 +08: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-07 04:42:45 +08:00
|
|
|
int ret;
|
2012-02-16 09:14:37 +08:00
|
|
|
|
2012-02-20 10:15:03 +08: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 23:46:15 +08:00
|
|
|
return -ENODEV;
|
2012-02-20 10:15:03 +08: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-07 04:42:45 +08:00
|
|
|
ret = fadump_setup_crash_memory_ranges();
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-02-16 09:14:37 +08:00
|
|
|
|
2019-09-11 22:48:57 +08:00
|
|
|
addr = fw_dump.fadumphdr_addr;
|
|
|
|
|
2012-02-16 09:14:37 +08: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 10:15:03 +08:00
|
|
|
/* register the future kernel dump with firmware. */
|
2019-09-11 22:48:57 +08:00
|
|
|
pr_debug("Registering for firmware-assisted kernel dump...\n");
|
|
|
|
return fw_dump.ops->fadump_register(&fw_dump);
|
2012-02-20 10:15:03 +08:00
|
|
|
}
|
|
|
|
|
2012-02-16 09:15:08 +08:00
|
|
|
void fadump_cleanup(void)
|
|
|
|
{
|
2019-09-11 22:51:16 +08:00
|
|
|
if (!fw_dump.fadump_supported)
|
|
|
|
return;
|
|
|
|
|
2012-02-16 09:15:08 +08:00
|
|
|
/* Invalidate the registration only if dump is active. */
|
|
|
|
if (fw_dump.dump_active) {
|
2019-09-11 22:49:44 +08:00
|
|
|
pr_debug("Invalidating firmware-assisted dump registration\n");
|
|
|
|
fw_dump.ops->fadump_invalidate(&fw_dump);
|
2018-04-27 14:23:18 +08:00
|
|
|
} else if (fw_dump.dump_registered) {
|
|
|
|
/* Un-register Firmware-assisted dump if it was registered. */
|
2019-09-11 22:48:57 +08:00
|
|
|
fw_dump.ops->fadump_unregister(&fw_dump);
|
2019-09-11 22:55:05 +08:00
|
|
|
fadump_free_mem_ranges(&crash_mrange_info);
|
2012-02-16 09:15:08 +08:00
|
|
|
}
|
2019-09-11 22:51:16 +08:00
|
|
|
|
|
|
|
if (fw_dump.ops->fadump_cleanup)
|
|
|
|
fw_dump.ops->fadump_cleanup(&fw_dump);
|
2012-02-16 09:15:08 +08:00
|
|
|
}
|
|
|
|
|
2017-06-02 03:40:10 +08: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.
|
|
|
|
*/
|
2019-09-11 22:55:36 +08:00
|
|
|
static void fadump_release_reserved_area(u64 start, u64 end)
|
2017-06-02 03:40:10 +08:00
|
|
|
{
|
2020-10-14 07:58:08 +08:00
|
|
|
unsigned long reg_spfn, reg_epfn;
|
|
|
|
u64 tstart, tend, spfn, epfn;
|
|
|
|
int i;
|
2017-06-02 03:40:10 +08:00
|
|
|
|
2019-09-11 22:55:36 +08:00
|
|
|
spfn = PHYS_PFN(start);
|
|
|
|
epfn = PHYS_PFN(end);
|
2020-10-14 07:58:03 +08:00
|
|
|
|
|
|
|
for_each_mem_pfn_range(i, MAX_NUMNODES, ®_spfn, ®_epfn, NULL) {
|
|
|
|
tstart = max_t(u64, spfn, reg_spfn);
|
|
|
|
tend = min_t(u64, epfn, reg_epfn);
|
|
|
|
|
2017-06-02 03:40:10 +08:00
|
|
|
if (tstart < tend) {
|
|
|
|
fadump_free_reserved_memory(tstart, tend);
|
|
|
|
|
2019-09-11 22:55:36 +08:00
|
|
|
if (tend == epfn)
|
2017-06-02 03:40:10 +08:00
|
|
|
break;
|
|
|
|
|
2019-09-11 22:55:36 +08:00
|
|
|
spfn = tend;
|
2017-06-02 03:40:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-02-16 09:15:08 +08:00
|
|
|
/*
|
2019-09-11 22:55:36 +08:00
|
|
|
* Sort the mem ranges in-place and merge adjacent ranges
|
|
|
|
* to minimize the memory ranges count.
|
2012-02-16 09:15:08 +08:00
|
|
|
*/
|
2019-09-11 22:55:36 +08:00
|
|
|
static void sort_and_merge_mem_ranges(struct fadump_mrange_info *mrange_info)
|
2012-02-16 09:15:08 +08:00
|
|
|
{
|
2019-09-11 22:55:36 +08:00
|
|
|
struct fadump_memory_range *mem_ranges;
|
|
|
|
struct fadump_memory_range tmp_range;
|
|
|
|
u64 base, size;
|
|
|
|
int i, j, idx;
|
|
|
|
|
|
|
|
if (!reserved_mrange_info.mem_range_cnt)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Sort the memory ranges */
|
|
|
|
mem_ranges = mrange_info->mem_ranges;
|
|
|
|
for (i = 0; i < mrange_info->mem_range_cnt; i++) {
|
|
|
|
idx = i;
|
|
|
|
for (j = (i + 1); j < mrange_info->mem_range_cnt; j++) {
|
|
|
|
if (mem_ranges[idx].base > mem_ranges[j].base)
|
|
|
|
idx = j;
|
|
|
|
}
|
|
|
|
if (idx != i) {
|
|
|
|
tmp_range = mem_ranges[idx];
|
|
|
|
mem_ranges[idx] = mem_ranges[i];
|
|
|
|
mem_ranges[i] = tmp_range;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Merge adjacent reserved ranges */
|
|
|
|
idx = 0;
|
|
|
|
for (i = 1; i < mrange_info->mem_range_cnt; i++) {
|
|
|
|
base = mem_ranges[i-1].base;
|
|
|
|
size = mem_ranges[i-1].size;
|
|
|
|
if (mem_ranges[i].base == (base + size))
|
|
|
|
mem_ranges[idx].size += mem_ranges[i].size;
|
|
|
|
else {
|
|
|
|
idx++;
|
|
|
|
if (i == idx)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
mem_ranges[idx] = mem_ranges[i];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mrange_info->mem_range_cnt = idx + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan reserved-ranges to consider them while reserving/releasing
|
|
|
|
* memory for FADump.
|
|
|
|
*/
|
2020-04-20 16:56:09 +08:00
|
|
|
static void __init early_init_dt_scan_reserved_ranges(unsigned long node)
|
2019-09-11 22:55:36 +08:00
|
|
|
{
|
|
|
|
const __be32 *prop;
|
|
|
|
int len, ret = -1;
|
|
|
|
unsigned long i;
|
|
|
|
|
2020-04-20 16:56:09 +08:00
|
|
|
/* reserved-ranges already scanned */
|
|
|
|
if (reserved_mrange_info.mem_range_cnt != 0)
|
|
|
|
return;
|
2019-09-11 22:55:36 +08:00
|
|
|
|
2020-04-20 16:56:09 +08:00
|
|
|
prop = of_get_flat_dt_prop(node, "reserved-ranges", &len);
|
2019-09-11 22:55:36 +08:00
|
|
|
if (!prop)
|
2020-04-20 16:56:09 +08:00
|
|
|
return;
|
2019-09-11 22:55:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Each reserved range is an (address,size) pair, 2 cells each,
|
|
|
|
* totalling 4 cells per range.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < len / (sizeof(*prop) * 4); i++) {
|
|
|
|
u64 base, size;
|
|
|
|
|
|
|
|
base = of_read_number(prop + (i * 4) + 0, 2);
|
|
|
|
size = of_read_number(prop + (i * 4) + 2, 2);
|
|
|
|
|
|
|
|
if (size) {
|
|
|
|
ret = fadump_add_mem_range(&reserved_mrange_info,
|
|
|
|
base, base + size);
|
|
|
|
if (ret < 0) {
|
|
|
|
pr_warn("some reserved ranges are ignored!\n");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-20 16:56:09 +08:00
|
|
|
/* Compact reserved ranges */
|
|
|
|
sort_and_merge_mem_ranges(&reserved_mrange_info);
|
2019-09-11 22:55:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Release the memory that was reserved during early boot to preserve the
|
|
|
|
* crash'ed kernel's memory contents except reserved dump area (permanent
|
|
|
|
* reservation) and reserved ranges used by F/W. The released memory will
|
|
|
|
* be available for general use.
|
|
|
|
*/
|
|
|
|
static void fadump_release_memory(u64 begin, u64 end)
|
|
|
|
{
|
|
|
|
u64 ra_start, ra_end, tstart;
|
|
|
|
int i, ret;
|
|
|
|
|
2012-02-16 09:15:08 +08:00
|
|
|
ra_start = fw_dump.reserve_dump_area_start;
|
|
|
|
ra_end = ra_start + fw_dump.reserve_dump_area_size;
|
|
|
|
|
2017-06-02 03:40:10 +08:00
|
|
|
/*
|
2020-04-20 16:56:09 +08:00
|
|
|
* If reserved ranges array limit is hit, overwrite the last reserved
|
|
|
|
* memory range with reserved dump area to ensure it is excluded from
|
|
|
|
* the memory being released (reused for next FADump registration).
|
2017-06-02 03:40:10 +08:00
|
|
|
*/
|
2020-04-20 16:56:09 +08:00
|
|
|
if (reserved_mrange_info.mem_range_cnt ==
|
|
|
|
reserved_mrange_info.max_mem_ranges)
|
|
|
|
reserved_mrange_info.mem_range_cnt--;
|
2019-09-11 22:55:36 +08:00
|
|
|
|
2020-04-20 16:56:09 +08:00
|
|
|
ret = fadump_add_mem_range(&reserved_mrange_info, ra_start, ra_end);
|
|
|
|
if (ret != 0)
|
2019-09-11 22:55:36 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
/* Get the reserved ranges list in order first. */
|
|
|
|
sort_and_merge_mem_ranges(&reserved_mrange_info);
|
|
|
|
|
|
|
|
/* Exclude reserved ranges and release remaining memory */
|
|
|
|
tstart = begin;
|
|
|
|
for (i = 0; i < reserved_mrange_info.mem_range_cnt; i++) {
|
|
|
|
ra_start = reserved_mrange_info.mem_ranges[i].base;
|
|
|
|
ra_end = ra_start + reserved_mrange_info.mem_ranges[i].size;
|
|
|
|
|
|
|
|
if (tstart >= ra_end)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (tstart < ra_start)
|
|
|
|
fadump_release_reserved_area(tstart, ra_start);
|
|
|
|
tstart = ra_end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tstart < end)
|
|
|
|
fadump_release_reserved_area(tstart, end);
|
2012-02-16 09:15:08 +08: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 22:57:39 +08:00
|
|
|
fadump_release_memory(fw_dump.boot_mem_top, memblock_end_of_DRAM());
|
2019-09-11 22:46:36 +08:00
|
|
|
fadump_free_cpu_notes_buf();
|
|
|
|
|
2019-09-11 22:53:28 +08:00
|
|
|
/*
|
|
|
|
* Setup kernel metadata and initialize the kernel dump
|
|
|
|
* memory structure for FADump re-registration.
|
|
|
|
*/
|
|
|
|
if (fw_dump.ops->fadump_setup_metadata &&
|
|
|
|
(fw_dump.ops->fadump_setup_metadata(&fw_dump) < 0))
|
|
|
|
pr_warn("Failed to setup kernel metadata!\n");
|
2019-09-11 22:48:57 +08:00
|
|
|
fw_dump.ops->fadump_init_mem_struct(&fw_dump);
|
2012-02-16 09:15:08 +08:00
|
|
|
}
|
|
|
|
|
2019-12-12 00:09:07 +08:00
|
|
|
static ssize_t release_mem_store(struct kobject *kobj,
|
|
|
|
struct kobj_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
2012-02-16 09:15:08 +08:00
|
|
|
{
|
2017-06-26 22:06:01 +08:00
|
|
|
int input = -1;
|
|
|
|
|
2012-02-16 09:15:08 +08:00
|
|
|
if (!fw_dump.dump_active)
|
|
|
|
return -EPERM;
|
|
|
|
|
2017-06-26 22:06:01 +08:00
|
|
|
if (kstrtoint(buf, 0, &input))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (input == 1) {
|
2012-02-16 09:15:08 +08:00
|
|
|
/*
|
|
|
|
* Take away the '/proc/vmcore'. We are releasing the dump
|
|
|
|
* memory, hence it will not be valid anymore.
|
|
|
|
*/
|
2016-09-30 08:51:46 +08:00
|
|
|
#ifdef CONFIG_PROC_VMCORE
|
2012-02-16 09:15:08 +08:00
|
|
|
vmcore_cleanup();
|
2016-09-30 08:51:46 +08:00
|
|
|
#endif
|
2012-02-16 09:15:08 +08:00
|
|
|
fadump_invalidate_release_mem();
|
|
|
|
|
|
|
|
} else
|
|
|
|
return -EINVAL;
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2019-12-12 00:09:07 +08:00
|
|
|
/* Release the reserved memory and disable the FADump */
|
2021-12-17 06:00:16 +08:00
|
|
|
static void __init unregister_fadump(void)
|
2019-12-12 00:09:07 +08:00
|
|
|
{
|
|
|
|
fadump_cleanup();
|
|
|
|
fadump_release_memory(fw_dump.reserve_dump_area_start,
|
|
|
|
fw_dump.reserve_dump_area_size);
|
|
|
|
fw_dump.fadump_enabled = 0;
|
|
|
|
kobject_put(fadump_kobj);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t enabled_show(struct kobject *kobj,
|
|
|
|
struct kobj_attribute *attr,
|
|
|
|
char *buf)
|
2012-02-20 10:15:03 +08:00
|
|
|
{
|
|
|
|
return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
|
|
|
|
}
|
|
|
|
|
2019-12-12 00:09:10 +08:00
|
|
|
static ssize_t mem_reserved_show(struct kobject *kobj,
|
|
|
|
struct kobj_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
return sprintf(buf, "%ld\n", fw_dump.reserve_dump_area_size);
|
|
|
|
}
|
|
|
|
|
2019-12-12 00:09:07 +08:00
|
|
|
static ssize_t registered_show(struct kobject *kobj,
|
|
|
|
struct kobj_attribute *attr,
|
|
|
|
char *buf)
|
2012-02-20 10:15:03 +08:00
|
|
|
{
|
|
|
|
return sprintf(buf, "%d\n", fw_dump.dump_registered);
|
|
|
|
}
|
|
|
|
|
2019-12-12 00:09:07 +08:00
|
|
|
static ssize_t registered_store(struct kobject *kobj,
|
|
|
|
struct kobj_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
2012-02-20 10:15:03 +08:00
|
|
|
{
|
|
|
|
int ret = 0;
|
2017-06-26 22:06:01 +08:00
|
|
|
int input = -1;
|
2012-02-20 10:15:03 +08:00
|
|
|
|
2019-09-11 22:49:44 +08:00
|
|
|
if (!fw_dump.fadump_enabled || fw_dump.dump_active)
|
2012-02-20 10:15:03 +08:00
|
|
|
return -EPERM;
|
|
|
|
|
2017-06-26 22:06:01 +08:00
|
|
|
if (kstrtoint(buf, 0, &input))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-02-20 10:15:03 +08:00
|
|
|
mutex_lock(&fadump_mutex);
|
|
|
|
|
2017-06-26 22:06:01 +08:00
|
|
|
switch (input) {
|
|
|
|
case 0:
|
2012-02-20 10:15:03 +08:00
|
|
|
if (fw_dump.dump_registered == 0) {
|
|
|
|
goto unlock_out;
|
|
|
|
}
|
2019-09-11 22:49:44 +08:00
|
|
|
|
2012-02-20 10:15:03 +08:00
|
|
|
/* Un-register Firmware-assisted dump */
|
2019-09-11 22:48:57 +08:00
|
|
|
pr_debug("Un-register firmware-assisted dump\n");
|
|
|
|
fw_dump.ops->fadump_unregister(&fw_dump);
|
2012-02-20 10:15:03 +08:00
|
|
|
break;
|
2017-06-26 22:06:01 +08:00
|
|
|
case 1:
|
2012-02-20 10:15:03 +08:00
|
|
|
if (fw_dump.dump_registered == 1) {
|
2018-09-14 22:06:02 +08:00
|
|
|
/* Un-register Firmware-assisted dump */
|
2019-09-11 22:48:57 +08:00
|
|
|
fw_dump.ops->fadump_unregister(&fw_dump);
|
2012-02-20 10:15:03 +08:00
|
|
|
}
|
|
|
|
/* Register Firmware-assisted dump */
|
2017-05-27 23:46:15 +08:00
|
|
|
ret = register_fadump();
|
2012-02-20 10:15:03 +08: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 09:15:08 +08:00
|
|
|
mutex_lock(&fadump_mutex);
|
2019-09-11 22:49:44 +08:00
|
|
|
fw_dump.ops->fadump_region_show(&fw_dump, m);
|
|
|
|
mutex_unlock(&fadump_mutex);
|
2012-02-20 10:15:03 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-12 00:09:07 +08:00
|
|
|
static struct kobj_attribute release_attr = __ATTR_WO(release_mem);
|
|
|
|
static struct kobj_attribute enable_attr = __ATTR_RO(enabled);
|
|
|
|
static struct kobj_attribute register_attr = __ATTR_RW(registered);
|
2019-12-12 00:09:10 +08:00
|
|
|
static struct kobj_attribute mem_reserved_attr = __ATTR_RO(mem_reserved);
|
2019-12-12 00:09:07 +08:00
|
|
|
|
|
|
|
static struct attribute *fadump_attrs[] = {
|
|
|
|
&enable_attr.attr,
|
|
|
|
®ister_attr.attr,
|
2019-12-12 00:09:10 +08:00
|
|
|
&mem_reserved_attr.attr,
|
2019-12-12 00:09:07 +08:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
ATTRIBUTE_GROUPS(fadump);
|
2012-02-20 10:15:03 +08:00
|
|
|
|
2018-11-05 23:01:19 +08:00
|
|
|
DEFINE_SHOW_ATTRIBUTE(fadump_region);
|
2012-02-20 10:15:03 +08:00
|
|
|
|
2021-12-17 06:00:16 +08:00
|
|
|
static void __init fadump_init_files(void)
|
2012-02-20 10:15:03 +08:00
|
|
|
{
|
|
|
|
int rc = 0;
|
|
|
|
|
2019-12-12 00:09:07 +08:00
|
|
|
fadump_kobj = kobject_create_and_add("fadump", kernel_kobj);
|
|
|
|
if (!fadump_kobj) {
|
|
|
|
pr_err("failed to create fadump kobject\n");
|
|
|
|
return;
|
|
|
|
}
|
2020-02-09 18:58:56 +08:00
|
|
|
|
2021-08-12 21:28:31 +08:00
|
|
|
debugfs_create_file("fadump_region", 0444, arch_debugfs_dir, NULL,
|
2020-02-09 18:58:56 +08:00
|
|
|
&fadump_region_fops);
|
2012-02-16 09:15:08 +08:00
|
|
|
|
|
|
|
if (fw_dump.dump_active) {
|
2019-12-12 00:09:07 +08:00
|
|
|
rc = sysfs_create_file(fadump_kobj, &release_attr.attr);
|
|
|
|
if (rc)
|
|
|
|
pr_err("unable to create release_mem sysfs file (%d)\n",
|
|
|
|
rc);
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = sysfs_create_groups(fadump_kobj, fadump_groups);
|
|
|
|
if (rc) {
|
|
|
|
pr_err("sysfs group creation failed (%d), unregistering FADump",
|
|
|
|
rc);
|
|
|
|
unregister_fadump();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The FADump sysfs are moved from kernel_kobj to fadump_kobj need to
|
|
|
|
* create symlink at old location to maintain backward compatibility.
|
|
|
|
*
|
|
|
|
* - fadump_enabled -> fadump/enabled
|
|
|
|
* - fadump_registered -> fadump/registered
|
|
|
|
* - fadump_release_mem -> fadump/release_mem
|
|
|
|
*/
|
|
|
|
rc = compat_only_sysfs_link_entry_to_kobj(kernel_kobj, fadump_kobj,
|
|
|
|
"enabled", "fadump_enabled");
|
|
|
|
if (rc) {
|
|
|
|
pr_err("unable to create fadump_enabled symlink (%d)", rc);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = compat_only_sysfs_link_entry_to_kobj(kernel_kobj, fadump_kobj,
|
|
|
|
"registered",
|
|
|
|
"fadump_registered");
|
|
|
|
if (rc) {
|
|
|
|
pr_err("unable to create fadump_registered symlink (%d)", rc);
|
|
|
|
sysfs_remove_link(kernel_kobj, "fadump_enabled");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fw_dump.dump_active) {
|
|
|
|
rc = compat_only_sysfs_link_entry_to_kobj(kernel_kobj,
|
|
|
|
fadump_kobj,
|
|
|
|
"release_mem",
|
|
|
|
"fadump_release_mem");
|
2012-02-16 09:15:08 +08:00
|
|
|
if (rc)
|
2019-12-12 00:09:07 +08:00
|
|
|
pr_err("unable to create fadump_release_mem symlink (%d)",
|
|
|
|
rc);
|
2012-02-16 09:15:08 +08:00
|
|
|
}
|
2012-02-20 10:15:03 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepare for firmware-assisted dump.
|
|
|
|
*/
|
|
|
|
int __init setup_fadump(void)
|
|
|
|
{
|
2019-11-08 00:47:57 +08:00
|
|
|
if (!fw_dump.fadump_supported)
|
2012-02-20 10:15:03 +08:00
|
|
|
return 0;
|
|
|
|
|
2019-11-08 00:47:57 +08:00
|
|
|
fadump_init_files();
|
2012-02-20 10:15:03 +08:00
|
|
|
fadump_show_config();
|
2019-11-08 00:47:57 +08:00
|
|
|
|
|
|
|
if (!fw_dump.fadump_enabled)
|
|
|
|
return 1;
|
|
|
|
|
2012-02-16 09:14:37 +08:00
|
|
|
/*
|
|
|
|
* If dump data is available then see if it is valid and prepare for
|
|
|
|
* saving it to the disk.
|
|
|
|
*/
|
2012-02-16 09:15:08 +08: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 22:49:44 +08:00
|
|
|
if (fw_dump.ops->fadump_process(&fw_dump) < 0)
|
2012-02-16 09:15:08 +08:00
|
|
|
fadump_invalidate_release_mem();
|
|
|
|
}
|
2022-02-01 18:53:05 +08:00
|
|
|
/* Initialize the kernel dump memory structure and register with f/w */
|
|
|
|
else if (fw_dump.reserve_dump_area_size) {
|
2019-09-11 22:48:57 +08:00
|
|
|
fw_dump.ops->fadump_init_mem_struct(&fw_dump);
|
2022-02-01 18:53:05 +08:00
|
|
|
register_fadump();
|
|
|
|
}
|
2019-09-11 22:49:44 +08:00
|
|
|
|
powerpc/fadump: Fix inaccurate CPU state info in vmcore generated with panic
In panic path, fadump is triggered via a panic notifier function.
Before calling panic notifier functions, smp_send_stop() gets called,
which stops all CPUs except the panic'ing CPU. Commit 8389b37dffdc
("powerpc: stop_this_cpu: remove the cpu from the online map.") and
again commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
started marking CPUs as offline while stopping them. So, if a kernel
has either of the above commits, vmcore captured with fadump via panic
path would not process register data for all CPUs except the panic'ing
CPU. Sample output of crash-utility with such vmcore:
# crash vmlinux vmcore
...
KERNEL: vmlinux
DUMPFILE: vmcore [PARTIAL DUMP]
CPUS: 1
DATE: Wed Nov 10 09:56:34 EST 2021
UPTIME: 00:00:42
LOAD AVERAGE: 2.27, 0.69, 0.24
TASKS: 183
NODENAME: XXXXXXXXX
RELEASE: 5.15.0+
VERSION: #974 SMP Wed Nov 10 04:18:19 CST 2021
MACHINE: ppc64le (2500 Mhz)
MEMORY: 8 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 3394
COMMAND: "bash"
TASK: c0000000150a5f80 [THREAD_INFO: c0000000150a5f80]
CPU: 1
STATE: TASK_RUNNING (PANIC)
crash> p -x __cpu_online_mask
__cpu_online_mask = $1 = {
bits = {0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
}
crash>
crash>
crash> p -x __cpu_active_mask
__cpu_active_mask = $2 = {
bits = {0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
}
crash>
While this has been the case since fadump was introduced, the issue
was not identified for two probable reasons:
- In general, the bulk of the vmcores analyzed were from crash
due to exception.
- The above did change since commit 8341f2f222d7 ("sysrq: Use
panic() to force a crash") started using panic() instead of
deferencing NULL pointer to force a kernel crash. But then
commit de6e5d38417e ("powerpc: smp_send_stop do not offline
stopped CPUs") stopped marking CPUs as offline till kernel
commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
reverted that change.
To ensure post processing register data of all other CPUs happens
as intended, let panic() function take the crash friendly path (read
crash_smp_send_stop()) with the help of crash_kexec_post_notifiers
option. Also, as register data for all CPUs is captured by f/w, skip
IPI callbacks here for fadump, to avoid any complications in finding
the right backtraces.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211207103719.91117-2-hbathini@linux.ibm.com
2021-12-07 18:37:19 +08:00
|
|
|
/*
|
|
|
|
* In case of panic, fadump is triggered via ppc_panic_event()
|
|
|
|
* panic notifier. Setting crash_kexec_post_notifiers to 'true'
|
|
|
|
* lets panic() function take crash friendly path before panic
|
|
|
|
* notifiers are invoked.
|
|
|
|
*/
|
|
|
|
crash_kexec_post_notifiers = true;
|
|
|
|
|
2012-02-20 10:15:03 +08:00
|
|
|
return 1;
|
|
|
|
}
|
2022-02-01 18:53:05 +08:00
|
|
|
/*
|
|
|
|
* Use subsys_initcall_sync() here because there is dependency with
|
|
|
|
* crash_save_vmcoreinfo_init(), which mush run first to ensure vmcoreinfo initialization
|
|
|
|
* is done before regisering with f/w.
|
|
|
|
*/
|
|
|
|
subsys_initcall_sync(setup_fadump);
|
2019-09-11 22:56:03 +08:00
|
|
|
#else /* !CONFIG_PRESERVE_FA_DUMP */
|
|
|
|
|
|
|
|
/* Scan the Firmware Assisted dump configuration details. */
|
|
|
|
int __init early_init_dt_scan_fw_dump(unsigned long node, const char *uname,
|
|
|
|
int depth, void *data)
|
|
|
|
{
|
|
|
|
if ((depth != 1) || (strcmp(uname, "ibm,opal") != 0))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
opal_fadump_dt_scan(&fw_dump, node);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When dump is active but PRESERVE_FA_DUMP is enabled on the kernel,
|
|
|
|
* preserve crash data. The subsequent memory preserving kernel boot
|
|
|
|
* is likely to process this crash data.
|
|
|
|
*/
|
|
|
|
int __init fadump_reserve_mem(void)
|
|
|
|
{
|
|
|
|
if (fw_dump.dump_active) {
|
|
|
|
/*
|
|
|
|
* If last boot has crashed then reserve all the memory
|
|
|
|
* above boot memory to preserve crash data.
|
|
|
|
*/
|
|
|
|
pr_info("Preserving crash data for processing in next boot.\n");
|
|
|
|
fadump_reserve_crash_area(fw_dump.boot_mem_top);
|
|
|
|
} else
|
|
|
|
pr_debug("FADump-aware kernel..\n");
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_PRESERVE_FA_DUMP */
|
2019-09-11 22:55:49 +08:00
|
|
|
|
|
|
|
/* Preserve everything above the base address */
|
|
|
|
static void __init fadump_reserve_crash_area(u64 base)
|
|
|
|
{
|
2020-10-14 07:58:08 +08:00
|
|
|
u64 i, mstart, mend, msize;
|
2019-09-11 22:55:49 +08:00
|
|
|
|
2020-10-14 07:58:08 +08:00
|
|
|
for_each_mem_range(i, &mstart, &mend) {
|
|
|
|
msize = mend - mstart;
|
2019-09-11 22:55:49 +08:00
|
|
|
|
|
|
|
if ((mstart + msize) < base)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (mstart < base) {
|
|
|
|
msize -= (base - mstart);
|
|
|
|
mstart = base;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_info("Reserving %lluMB of memory at %#016llx for preserving crash data",
|
|
|
|
(msize >> 20), mstart);
|
|
|
|
memblock_reserve(mstart, msize);
|
|
|
|
}
|
|
|
|
}
|
2019-09-11 22:56:03 +08:00
|
|
|
|
|
|
|
unsigned long __init arch_reserved_kernel_pages(void)
|
|
|
|
{
|
|
|
|
return memblock_reserved_size() / PAGE_SIZE;
|
|
|
|
}
|