Compare commits
2
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
685ab7d355 | ||
|
|
33df58d33e |
@@ -1,5 +1,5 @@
|
||||
--- crash-8.0.4/diskdump.c.orig
|
||||
+++ crash-8.0.4/diskdump.c
|
||||
--- crash-8.0.2/diskdump.c.orig
|
||||
+++ crash-8.0.2/diskdump.c
|
||||
@@ -23,6 +23,9 @@
|
||||
* GNU General Public License for more details.
|
||||
*/
|
||||
@@ -10,8 +10,8 @@
|
||||
#include "defs.h"
|
||||
#include "diskdump.h"
|
||||
#include "xen_dom0.h"
|
||||
--- crash-8.0.4/Makefile.orig
|
||||
+++ crash-8.0.4/Makefile
|
||||
--- crash-8.0.2/Makefile.orig
|
||||
+++ crash-8.0.2/Makefile
|
||||
@@ -256,7 +256,7 @@ all: make_configure
|
||||
gdb_merge: force
|
||||
@if [ ! -f ${GDB}/README ]; then \
|
||||
|
||||
@@ -40,9 +40,9 @@ index c3e26a3..d293e6c 100644
|
||||
--- a/arm64.c
|
||||
+++ b/arm64.c
|
||||
@@ -93,6 +93,11 @@ static void arm64_calc_VA_BITS(void);
|
||||
static int arm64_is_uvaddr(ulong, struct task_context *);
|
||||
static void arm64_calc_KERNELPACMASK(void);
|
||||
static int arm64_get_vmcoreinfo(unsigned long *vaddr, const char *label, int base);
|
||||
|
||||
|
||||
+static int arm64_in_sdei_normal_stack(int cpu, ulong stkptr);
|
||||
+static void arm64_set_sdei_normal_stack(struct bt_info *bt);
|
||||
+static void arm64_sdei_stack_init(void);
|
||||
|
||||
@@ -0,0 +1,148 @@
|
||||
From 5f27639196c3240810fbf30d367da0063a6612ff Mon Sep 17 00:00:00 2001
|
||||
From: Ding Hui <dinghui@sangfor.com.cn>
|
||||
Date: Thu, 1 Dec 2022 15:01:45 +0800
|
||||
Subject: [PATCH] arm64: fix backtraces of KASAN kernel dumpfile truncated
|
||||
|
||||
We met "bt" command on KASAN kernel vmcore display truncated backtraces
|
||||
like this:
|
||||
|
||||
crash> bt
|
||||
PID: 4131 TASK: ffff8001521df000 CPU: 3 COMMAND: "bash"
|
||||
#0 [ffff2000224b0cb0] machine_kexec_prepare at ffff2000200bff4c
|
||||
|
||||
After digging the root cause, it turns out that arm64_in_kdump_text()
|
||||
found wrong bt->bptr at "machine_kexec" branch.
|
||||
|
||||
Disassemble machine_kexec() of KASAN vmlinux (gcc 7.3.0):
|
||||
|
||||
crash> dis -x machine_kexec
|
||||
0xffff2000200bff50 <machine_kexec>: stp x29, x30, [sp,#-208]!
|
||||
0xffff2000200bff54 <machine_kexec+0x4>: mov x29, sp
|
||||
0xffff2000200bff58 <machine_kexec+0x8>: stp x19, x20, [sp,#16]
|
||||
0xffff2000200bff5c <machine_kexec+0xc>: str x24, [sp,#56]
|
||||
0xffff2000200bff60 <machine_kexec+0x10>: str x26, [sp,#72]
|
||||
0xffff2000200bff64 <machine_kexec+0x14>: mov x2, #0x8ab3
|
||||
0xffff2000200bff68 <machine_kexec+0x18>: add x1, x29, #0x70
|
||||
0xffff2000200bff6c <machine_kexec+0x1c>: lsr x1, x1, #3
|
||||
0xffff2000200bff70 <machine_kexec+0x20>: movk x2, #0x41b5, lsl #16
|
||||
0xffff2000200bff74 <machine_kexec+0x24>: mov x19, #0x200000000000
|
||||
0xffff2000200bff78 <machine_kexec+0x28>: adrp x3, 0xffff2000224b0000
|
||||
0xffff2000200bff7c <machine_kexec+0x2c>: movk x19, #0xdfff, lsl #48
|
||||
0xffff2000200bff80 <machine_kexec+0x30>: add x3, x3, #0xcb0
|
||||
0xffff2000200bff84 <machine_kexec+0x34>: add x4, x1, x19
|
||||
0xffff2000200bff88 <machine_kexec+0x38>: stp x2, x3, [x29,#112]
|
||||
0xffff2000200bff8c <machine_kexec+0x3c>: adrp x2, 0xffff2000200bf000 <swsusp_arch_resume+0x1e8>
|
||||
0xffff2000200bff90 <machine_kexec+0x40>: add x2, x2, #0xf50
|
||||
0xffff2000200bff94 <machine_kexec+0x44>: str x2, [x29,#128]
|
||||
0xffff2000200bff98 <machine_kexec+0x48>: mov w2, #0xf1f1f1f1
|
||||
0xffff2000200bff9c <machine_kexec+0x4c>: str w2, [x1,x19]
|
||||
0xffff2000200bffa0 <machine_kexec+0x50>: mov w2, #0xf200
|
||||
0xffff2000200bffa4 <machine_kexec+0x54>: mov w1, #0xf3f3f3f3
|
||||
0xffff2000200bffa8 <machine_kexec+0x58>: movk w2, #0xf2f2, lsl #16
|
||||
0xffff2000200bffac <machine_kexec+0x5c>: stp w2, w1, [x4,#4]
|
||||
|
||||
We notice that:
|
||||
1. machine_kexec() start address is 0xffff2000200bff50
|
||||
2. the instruction at machine_kexec+0x44 stores the same value
|
||||
0xffff2000200bff50 (comes from 0xffff2000200bf000 + 0xf50)
|
||||
into stack postion [x29,#128].
|
||||
|
||||
When arm64_in_kdump_text() searches for LR from stack, it met
|
||||
0xffff2000200bff50 firstly, so got wrong bt->bptr.
|
||||
|
||||
We know that the real LR is always greater than the start address
|
||||
of a function, so let's fix it by changing the search conditon to
|
||||
(*ptr > xxx_start) && (*ptr < xxx_end).
|
||||
|
||||
Signed-off-by: Ding Hui <dinghui@sangfor.com.cn>
|
||||
---
|
||||
arm64.c | 18 +++++++++---------
|
||||
1 file changed, 9 insertions(+), 9 deletions(-)
|
||||
|
||||
diff --git a/arm64.c b/arm64.c
|
||||
index c3e26a3..7e8a7db 100644
|
||||
--- a/arm64.c
|
||||
+++ b/arm64.c
|
||||
@@ -3479,7 +3479,7 @@ arm64_in_kdump_text(struct bt_info *bt, struct arm64_stackframe *frame)
|
||||
ms = machdep->machspec;
|
||||
for (ptr = start - 8; ptr >= base; ptr--) {
|
||||
if (bt->flags & BT_OPT_BACK_TRACE) {
|
||||
- if ((*ptr >= ms->crash_kexec_start) &&
|
||||
+ if ((*ptr > ms->crash_kexec_start) &&
|
||||
(*ptr < ms->crash_kexec_end) &&
|
||||
INSTACK(*(ptr - 1), bt)) {
|
||||
bt->bptr = ((ulong)(ptr - 1) - (ulong)base)
|
||||
@@ -3488,7 +3488,7 @@ arm64_in_kdump_text(struct bt_info *bt, struct arm64_stackframe *frame)
|
||||
fprintf(fp, "%lx: %lx (crash_kexec)\n", bt->bptr, *ptr);
|
||||
return TRUE;
|
||||
}
|
||||
- if ((*ptr >= ms->crash_save_cpu_start) &&
|
||||
+ if ((*ptr > ms->crash_save_cpu_start) &&
|
||||
(*ptr < ms->crash_save_cpu_end) &&
|
||||
INSTACK(*(ptr - 1), bt)) {
|
||||
bt->bptr = ((ulong)(ptr - 1) - (ulong)base)
|
||||
@@ -3498,14 +3498,14 @@ arm64_in_kdump_text(struct bt_info *bt, struct arm64_stackframe *frame)
|
||||
return TRUE;
|
||||
}
|
||||
} else {
|
||||
- if ((*ptr >= ms->machine_kexec_start) && (*ptr < ms->machine_kexec_end)) {
|
||||
+ if ((*ptr > ms->machine_kexec_start) && (*ptr < ms->machine_kexec_end)) {
|
||||
bt->bptr = ((ulong)ptr - (ulong)base)
|
||||
+ task_to_stackbase(bt->tc->task);
|
||||
if (CRASHDEBUG(1))
|
||||
fprintf(fp, "%lx: %lx (machine_kexec)\n", bt->bptr, *ptr);
|
||||
return TRUE;
|
||||
}
|
||||
- if ((*ptr >= ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
|
||||
+ if ((*ptr > ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
|
||||
/*
|
||||
* Stash the first crash_kexec frame in case the machine_kexec
|
||||
* frame is not found.
|
||||
@@ -3519,7 +3519,7 @@ arm64_in_kdump_text(struct bt_info *bt, struct arm64_stackframe *frame)
|
||||
}
|
||||
continue;
|
||||
}
|
||||
- if ((*ptr >= ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
|
||||
+ if ((*ptr > ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
|
||||
bt->bptr = ((ulong)ptr - (ulong)base)
|
||||
+ task_to_stackbase(bt->tc->task);
|
||||
if (CRASHDEBUG(1))
|
||||
@@ -3566,7 +3566,7 @@ arm64_in_kdump_text_on_irq_stack(struct bt_info *bt)
|
||||
|
||||
for (ptr = start - 8; ptr >= base; ptr--) {
|
||||
if (bt->flags & BT_OPT_BACK_TRACE) {
|
||||
- if ((*ptr >= ms->crash_kexec_start) &&
|
||||
+ if ((*ptr > ms->crash_kexec_start) &&
|
||||
(*ptr < ms->crash_kexec_end) &&
|
||||
INSTACK(*(ptr - 1), bt)) {
|
||||
bt->bptr = ((ulong)(ptr - 1) - (ulong)base) + stackbase;
|
||||
@@ -3576,7 +3576,7 @@ arm64_in_kdump_text_on_irq_stack(struct bt_info *bt)
|
||||
FREEBUF(stackbuf);
|
||||
return TRUE;
|
||||
}
|
||||
- if ((*ptr >= ms->crash_save_cpu_start) &&
|
||||
+ if ((*ptr > ms->crash_save_cpu_start) &&
|
||||
(*ptr < ms->crash_save_cpu_end) &&
|
||||
INSTACK(*(ptr - 1), bt)) {
|
||||
bt->bptr = ((ulong)(ptr - 1) - (ulong)base) + stackbase;
|
||||
@@ -3587,7 +3587,7 @@ arm64_in_kdump_text_on_irq_stack(struct bt_info *bt)
|
||||
return TRUE;
|
||||
}
|
||||
} else {
|
||||
- if ((*ptr >= ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
|
||||
+ if ((*ptr > ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
|
||||
bt->bptr = ((ulong)ptr - (ulong)base) + stackbase;
|
||||
if (CRASHDEBUG(1))
|
||||
fprintf(fp, "%lx: %lx (crash_kexec on IRQ stack)\n",
|
||||
@@ -3595,7 +3595,7 @@ arm64_in_kdump_text_on_irq_stack(struct bt_info *bt)
|
||||
FREEBUF(stackbuf);
|
||||
return TRUE;
|
||||
}
|
||||
- if ((*ptr >= ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
|
||||
+ if ((*ptr > ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
|
||||
bt->bptr = ((ulong)ptr - (ulong)base) + stackbase;
|
||||
if (CRASHDEBUG(1))
|
||||
fprintf(fp, "%lx: %lx (crash_save_cpu on IRQ stack)\n",
|
||||
--
|
||||
2.33.0
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,72 +0,0 @@
|
||||
From af895b219876b293d551e6dec825aba3905c0588 Mon Sep 17 00:00:00 2001
|
||||
From: "qiwu.chen" <qiwu.chen@transsion.com>
|
||||
Date: Wed, 24 Jul 2024 01:36:09 +0000
|
||||
Subject: [PATCH] arm64: fix a potential segfault when unwind frame
|
||||
|
||||
The range of frame->fp is checked insufficiently, which may lead to a wrong
|
||||
next fp. As a result, bt->stackbuf will be accessed out of range, and segfault.
|
||||
|
||||
crash> bt
|
||||
[Detaching after fork from child process 11409]
|
||||
PID: 7661 TASK: ffffff81858aa500 CPU: 4 COMMAND: "sh"
|
||||
#0 [ffffffc008003f50] local_cpu_stop at ffffffdd7669444c
|
||||
|
||||
Thread 1 "crash" received signal SIGSEGV, Segmentation fault.
|
||||
0x00005555558266cc in arm64_unwind_frame (bt=0x7fffffffd8f0, frame=0x7fffffffd080) at
|
||||
arm64.c:2821
|
||||
2821 frame->fp = GET_STACK_ULONG(fp);
|
||||
(gdb) bt
|
||||
arm64.c:2821
|
||||
out>) at main.c:1338
|
||||
gdb_interface.c:81
|
||||
(gdb) p /x *(struct bt_info*) 0x7fffffffd8f0
|
||||
$3 = {task = 0xffffff81858aa500, flags = 0x0, instptr = 0xffffffdd76694450, stkptr =
|
||||
0xffffffc008003f40, bptr = 0x0, stackbase = 0xffffffc027288000,
|
||||
stacktop = 0xffffffc02728c000, stackbuf = 0x555556115a40, tc = 0x55559d16fdc0, hp = 0x0,
|
||||
textlist = 0x0, ref = 0x0, frameptr = 0xffffffc008003f50,
|
||||
call_target = 0x0, machdep = 0x0, debug = 0x0, eframe_ip = 0x0, radix = 0x0, cpumask =
|
||||
0x0}
|
||||
(gdb) p /x *(struct arm64_stackframe*) 0x7fffffffd080
|
||||
$4 = {fp = 0xffffffc008003f50, sp = 0xffffffc008003f60, pc = 0xffffffdd76694450}
|
||||
crash> bt -S 0xffffffc008003f50
|
||||
PID: 7661 TASK: ffffff81858aa500 CPU: 4 COMMAND: "sh"
|
||||
bt: non-process stack address for this task: ffffffc008003f50
|
||||
(valid range: ffffffc027288000 - ffffffc02728c000)
|
||||
|
||||
Check frame->fp value sufficiently before access it. Only frame->fp within
|
||||
the range of bt->stackbase and bt->stacktop will be regarded as valid.
|
||||
|
||||
Signed-off-by: qiwu.chen <qiwu.chen@transsion.com>
|
||||
|
||||
Conflict: NA
|
||||
Reference: https://github.com/crash-utility/crash/commit/af895b219876b293d551e6dec825aba3905c0588
|
||||
|
||||
---
|
||||
arm64.c | 4 ++--
|
||||
1 file changed, 2 insertions(+), 2 deletions(-)
|
||||
|
||||
diff --git a/arm64.c b/arm64.c
|
||||
index b3040d7..624dba2 100644
|
||||
--- a/arm64.c
|
||||
+++ b/arm64.c
|
||||
@@ -2814,7 +2814,7 @@ arm64_unwind_frame(struct bt_info *bt, struct arm64_stackframe *frame)
|
||||
low = frame->sp;
|
||||
high = (low + stack_mask) & ~(stack_mask);
|
||||
|
||||
- if (fp < low || fp > high || fp & 0xf)
|
||||
+ if (fp < low || fp > high || fp & 0xf || !INSTACK(fp, bt))
|
||||
return FALSE;
|
||||
|
||||
frame->sp = fp + 0x10;
|
||||
@@ -3024,7 +3024,7 @@ arm64_unwind_frame_v2(struct bt_info *bt, struct arm64_stackframe *frame,
|
||||
low = frame->sp;
|
||||
high = (low + stack_mask) & ~(stack_mask);
|
||||
|
||||
- if (fp < low || fp > high || fp & 0xf)
|
||||
+ if (fp < low || fp > high || fp & 0xf || !INSTACK(fp, bt))
|
||||
return FALSE;
|
||||
|
||||
if (CRASHDEBUG(1))
|
||||
--
|
||||
2.33.0
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
From 45685956da58b15d4542d59b95888b1968980c68 Mon Sep 17 00:00:00 2001
|
||||
From: Xiaoguang Wang <lege.wang@jaguarmicro.com>
|
||||
Date: Thu, 7 Nov 2024 14:40:07 +0800
|
||||
Subject: [PATCH] arm64: fix SDEI stack frame unwind while UNW_4_14 is set
|
||||
|
||||
Fix two bugs:
|
||||
1) If BT_IRQSTACK is set, both irq_stack and sdei_normal_stack need
|
||||
to be checked while switching to process stack.
|
||||
2) Use bt->frameptr in arm64_unwind_frame() just like irq stack.
|
||||
|
||||
Fixes: 442da89f4898 ("crash: add SDEI stack resolution")
|
||||
Signed-off-by: Xiaoguang Wang <lege.wang@jaguarmicro.com>
|
||||
---
|
||||
arm64.c | 8 ++++----
|
||||
1 file changed, 4 insertions(+), 4 deletions(-)
|
||||
|
||||
diff --git a/arm64.c b/arm64.c
|
||||
index b99baa3..34c3b08 100644
|
||||
--- a/arm64.c
|
||||
+++ b/arm64.c
|
||||
@@ -3244,10 +3244,10 @@ arm64_unwind_frame(struct bt_info *bt, struct arm64_stackframe *frame)
|
||||
|
||||
if (machdep->flags & UNW_4_14) {
|
||||
if (((bt->flags & BT_IRQSTACK) &&
|
||||
- !arm64_on_irq_stack(bt->tc->processor, frame->fp)) ||
|
||||
+ !arm64_on_irq_stack(bt->tc->processor, frame->fp) &&
|
||||
+ !arm64_in_sdei_normal_stack(bt->tc->processor, frame->fp)) ||
|
||||
((bt->flags & BT_OVERFLOW_STACK) &&
|
||||
- !arm64_on_overflow_stack(bt->tc->processor, frame->fp)) &&
|
||||
- !arm64_in_sdei_normal_stack(bt->tc->processor, frame->fp)) {
|
||||
+ !arm64_on_overflow_stack(bt->tc->processor, frame->fp))) {
|
||||
if (arm64_on_process_stack(bt, frame->fp)) {
|
||||
arm64_set_process_stack(bt);
|
||||
|
||||
@@ -3696,7 +3696,7 @@ arm64_back_trace_cmd(struct bt_info *bt)
|
||||
arm64_set_overflow_stack(bt);
|
||||
bt->flags |= BT_OVERFLOW_STACK;
|
||||
}
|
||||
- if (arm64_in_sdei_normal_stack(bt->tc->processor, bt->bptr)) {
|
||||
+ if (arm64_in_sdei_normal_stack(bt->tc->processor, bt->frameptr)) {
|
||||
arm64_set_sdei_normal_stack(bt);
|
||||
bt->flags |= BT_IRQSTACK;
|
||||
}
|
||||
--
|
||||
2.34.1
|
||||
|
||||
Binary file not shown.
Binary file not shown.
@@ -1,66 +0,0 @@
|
||||
From db0077614aaeda6d0ed557f2b91d3349d5fe430f Mon Sep 17 00:00:00 2001
|
||||
From: Austin Kim <austindh.kim@gmail.com>
|
||||
Date: Tue, 29 Oct 2024 17:32:07 +0900
|
||||
Subject: [PATCH] Fix for 'sys' to properly display the PANIC message
|
||||
|
||||
Using 'sys' command, we can view the panic message with general system
|
||||
information. If we run RISCV64-based vmcore, PANIC message is not properly
|
||||
displayed.
|
||||
|
||||
The reason is that the string "Unable to handle kernel" is not
|
||||
completely matched with the panic_msg[]. The corresponding kernel commit
|
||||
is 21733cb518471.
|
||||
|
||||
Without the patch:
|
||||
crash> sys
|
||||
KERNEL: vmlinux [TAINTED]
|
||||
DUMPFILE: vmcore
|
||||
CPUS: 4
|
||||
DATE: Thu Aug 22 16:13:08 KST 2024
|
||||
UPTIME: 00:33:25
|
||||
LOAD AVERAGE: 0.07, 0.07, 0.02
|
||||
TASKS: 385
|
||||
NODENAME: starfive
|
||||
RELEASE: 6.6.20+
|
||||
VERSION: #13 SMP Mon Aug 19 12:58:52 KST 2024
|
||||
MACHINE: riscv64 (unknown Mhz)
|
||||
MEMORY: 4 GB
|
||||
PANIC: ""
|
||||
|
||||
With the patch:
|
||||
crash> sys
|
||||
KERNEL: vmlinux [TAINTED]
|
||||
DUMPFILE: vmcore
|
||||
CPUS: 4
|
||||
DATE: Thu Aug 22 16:13:08 KST 2024
|
||||
UPTIME: 00:33:25
|
||||
LOAD AVERAGE: 0.07, 0.07, 0.02
|
||||
TASKS: 385
|
||||
NODENAME: starfive
|
||||
RELEASE: 6.6.20+
|
||||
VERSION: #13 SMP Mon Aug 19 12:58:52 KST 2024
|
||||
MACHINE: riscv64 (unknown Mhz)
|
||||
MEMORY: 4 GB
|
||||
PANIC: "Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000000"
|
||||
|
||||
Signed-off-by: Austin Kim <austindh.kim@gmail.com>
|
||||
---
|
||||
task.c | 5 +++++
|
||||
1 file changed, 5 insertions(+)
|
||||
|
||||
diff --git a/task.c b/task.c
|
||||
index c131cc32..33de7da2 100644
|
||||
--- a/task.c
|
||||
+++ b/task.c
|
||||
@@ -6392,6 +6392,11 @@ get_panicmsg(char *buf)
|
||||
get_symbol_data("sysrq_pressed", sizeof(int), &msg_found);
|
||||
break;
|
||||
}
|
||||
+
|
||||
+ /*
|
||||
+ * Try to search panic string in panic keywords
|
||||
+ */
|
||||
+ search_panic_task_by_keywords(buf, &msg_found);
|
||||
}
|
||||
|
||||
found:
|
||||
+9
-77
@@ -1,22 +1,18 @@
|
||||
Name: crash
|
||||
Version: 8.0.5
|
||||
Release: 9
|
||||
Version: 8.0.2
|
||||
Release: 1
|
||||
Summary: Linux kernel crash utility.
|
||||
License: GPLv3
|
||||
URL: https://crash-utility.github.io
|
||||
Source0: https://github.com/crash-utility/crash/archive/refs/tags/%{version}.tar.gz
|
||||
Source0: https://github.com/crash-utility/crash/archive/%{version}.tar.gz
|
||||
Source1: http://ftp.gnu.org/gnu/gdb/gdb-10.2.tar.gz
|
||||
|
||||
Patch0: 0000-lzo_snappy.patch
|
||||
Patch1: 0001-add-SDEI-stack-resolution.patch
|
||||
Patch2: 0002-crash-8.0.2-sw.patch
|
||||
Patch3: 0003-crash-8.0.4-add-support-for-loongarch64.patch
|
||||
Patch4: 0004-arm64-fix-a-potential-segfault-when-unwind-frame.patch
|
||||
Patch5: 0005-arm64-fix-SDEI-stack-frame-unwind-while-UNW_4_14-is-.patch
|
||||
Patch9001: huawei-fix-ps-error-when-mm_struct.rss_stat-is-lazy-initial.patch
|
||||
%ifarch riscv64
|
||||
Patch6: backport-fix-for-sys-to-properly-display-the-PANIC-m.patch
|
||||
Patch1: 0000-lzo_snappy.patch
|
||||
Patch2: 0001-add-SDEI-stack-resolution.patch
|
||||
%ifarch sw_64
|
||||
Patch3: 0002-crash-8.0.2-sw.patch
|
||||
%endif
|
||||
Patch4: 0003-arm64-fix-backtraces-of-KASAN-kernel-dumpfile-truncated.patch
|
||||
|
||||
BuildRequires: ncurses-devel zlib-devel lzo-devel snappy-devel texinfo libzstd-devel
|
||||
BuildRequires: gcc gcc-c++ bison m4
|
||||
@@ -47,24 +43,7 @@ created by manufacturer-specific firmware.
|
||||
%package_help
|
||||
|
||||
%prep
|
||||
%setup -n %{name}-%{version}
|
||||
|
||||
%patch 0 -p1
|
||||
%patch 1 -p1
|
||||
|
||||
%ifarch sw_64
|
||||
%patch 2 -p1
|
||||
%endif
|
||||
%ifarch loongarch64
|
||||
%patch 3 -p1
|
||||
%endif
|
||||
|
||||
%patch 4 -p1
|
||||
%patch 5 -p1
|
||||
%patch 9001 -p1
|
||||
%ifarch riscv64
|
||||
%patch 6 -p1
|
||||
%endif
|
||||
%autosetup -n %{name}-%{version} -p1
|
||||
|
||||
%build
|
||||
cp %{SOURCE1} .
|
||||
@@ -99,53 +78,6 @@ install -D -m 0644 defs.h %{buildroot}%{_includedir}/%{name}/defs.h
|
||||
%{_mandir}/man8/crash.8*
|
||||
|
||||
%changelog
|
||||
* Mon Jul 14 2025 liuzhilin <liuzhilin@kylinos.cn> - 8.0.5-9
|
||||
- backport Fix for 'sys' to properly display the PANIC message patch.
|
||||
|
||||
* Wed Jun 04 2025 wangxiao <wangxiao184@h-partners.com> - 8.0.5-8
|
||||
- use patch command to apply patches for consistency in context
|
||||
|
||||
* Wed May 21 2025 zhangjian <zhangjian496@huawei.com> - 8.0.5-7
|
||||
- fix ps error when mm_struct.rss_stat is lazy initialized
|
||||
|
||||
* Wed Dec 04 2024 yangzhenyu <dev11101@linx-info.com> - 8.0.5-6
|
||||
- remove the architecture judgment in the patches section;
|
||||
- include all patches in the source package.
|
||||
|
||||
* Wed Nov 20 2024 Xiaoguang Wang <lege.wang@jaguarmicro.com> - 8.0.5-5
|
||||
- arm64: fix SDEI stack frame unwind while UNW_4_14 is set
|
||||
|
||||
* Wed Nov 13 2024 wangxiao <wangxiao184@h-partners.com> - 8.0.5-4
|
||||
- use autosetup instead of setup in prep stage
|
||||
|
||||
* Tue Nov 12 2024 wangxiao <wangxiao184@h-partners.com> - 8.0.5-3
|
||||
- arm64: fix a potential segfault when unwind frame
|
||||
|
||||
* Tue Nov 05 2024 xuguangmin <xuguangmin@kylinos.cn> - 8.0.5-2
|
||||
- Fix build warning:%patchN is deprecated (3 usages found), use %patch N
|
||||
|
||||
* Thu Jul 25 2024 dillon chen<dillon.chen@gmail.com> - 8.0.5-1
|
||||
- Upgrade to crash-8.0.5
|
||||
|
||||
* Tue May 28 2024 shaojiansong <shaojiansong@kylinos.cn> - 8.0.4-3
|
||||
- Fix lack of loongarch64 and sw_64 patch files in src.rpm package which is build from any platform.
|
||||
|
||||
* Tue Apr 16 2024 Pengda Dou <doupengda@loongson.cn> - 8.0.4-2
|
||||
- Resolve loongarch64 patch add error
|
||||
- add support for loongarch64
|
||||
|
||||
* Thu Jan 25 2024 chenhaixiang<chenhaixiang3@huawei.com> - 8.0.4-1
|
||||
- Upgrade to crash-8.0.4
|
||||
|
||||
* Tue Aug 1 2023 chenhaixiang<chenhaixiang3@huawei.com> - 8.0.2-4
|
||||
- Fix compilation error due to new strlcpy function that glibc added
|
||||
|
||||
* Mon Jul 10 2023 wangming <wangming01@loongson.cn> - 8.0.2-3
|
||||
- add LoongArch64 support.
|
||||
|
||||
* Fri Jul 7 2023 EastDong <xudong23@iscas.ac.cn> - 8.0.2-2
|
||||
- add riscv64 support
|
||||
|
||||
* Sun Jan 29 2023 chenhaixiang<chenhaixiang3@huawei.com> - 8.0.2-1
|
||||
- update to crash-8.0.2
|
||||
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
From 45052609f61d5d4ee8286d0d6098e53ea6b199a9 Mon Sep 17 00:00:00 2001
|
||||
From: zhangjian <zhangjian496@huawei.com>
|
||||
Date: Wed, 21 May 2025 02:08:12 +0000
|
||||
Subject: [PATCH] tmp
|
||||
|
||||
---
|
||||
tools.c | 5 +++++
|
||||
1 file changed, 5 insertions(+)
|
||||
|
||||
diff --git a/tools.c b/tools.c
|
||||
index 0f2db10..727a12c 100644
|
||||
--- a/tools.c
|
||||
+++ b/tools.c
|
||||
@@ -6955,6 +6955,11 @@ percpu_counter_sum_positive(ulong fbc)
|
||||
readmem(fbc + OFFSET(percpu_counter_counters), KVADDR, &addr,
|
||||
sizeof(void *), "percpu_counter.counters", FAULT_ON_ERROR);
|
||||
|
||||
+ /* maybe mm_struct.rss_stat is lazy initialized */
|
||||
+ if (!addr) {
|
||||
+ return ret;
|
||||
+ }
|
||||
+
|
||||
for (i = 0; i < kt->cpus; i++) {
|
||||
readmem(addr + kt->__per_cpu_offset[i], KVADDR, &count,
|
||||
sizeof(int), "percpu_counter.counters count", FAULT_ON_ERROR);
|
||||
--
|
||||
2.33.0
|
||||
|
||||
Reference in New Issue
Block a user