[PATCH] Fix: move huge compressed obj from page to zspage
by 陈冠有
when zspage define 'huge', crash-utility zram decompress fail.
we need to be compatible with the previous kernel,
so we can't define 'huge' directly in zspage, just move to the right when calculating.
Link: https://lkml.kernel.org/r/20211115185909.3949505-6-minchan@kernel.org
Signed-off-by: chenguanyou <chenguanyou(a)xiaomi.com>
---
defs.h | 4 ++++
diskdump.c | 21 ++++++++++++++++-----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/defs.h b/defs.h
index 96a7a2a..ac19410 100644
--- a/defs.h
+++ b/defs.h
@@ -2225,6 +2225,7 @@ struct offset_table { /* stash of commonly-used offsets */
long module_memory_base;
long module_memory_size;
long irq_data_irq;
+ long zspage_huge;
};
struct size_table { /* stash of commonly-used sizes */
@@ -7212,6 +7213,9 @@ ulong try_zram_decompress(ulonglong pte_val, unsigned char *buf, ulong len, ulon
#define ZRAM_FLAG_SAME_BIT (1<<25)
struct zspage {
struct {
+ // Link: https://lkml.kernel.org/r/20211115185909.3949505-6-minchan@kernel.org
+ // unsigned int huge : 1; // compatible
+
unsigned int fullness : 2;
unsigned int class : 9;
unsigned int isolated : 3;
diff --git a/diskdump.c b/diskdump.c
index 2c284ff..891ee2f 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -2764,6 +2764,8 @@ zram_object_addr(ulong pool, ulong handle, unsigned char *zram_buf)
physaddr_t paddr;
unsigned int obj_idx, class_idx, size;
ulong pages[2], sizes[2];
+ ulong zspage_shift = 0;
+ ulong zs_magic;
readmem(handle, KVADDR, &obj, sizeof(void *), "zram entry", FAULT_ON_ERROR);
obj >>= OBJ_TAG_BITS;
@@ -2774,9 +2776,13 @@ zram_object_addr(ulong pool, ulong handle, unsigned char *zram_buf)
sizeof(void *), "page_private", FAULT_ON_ERROR);
readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "zspage", FAULT_ON_ERROR);
- class_idx = zspage_s.class;
- if (zspage_s.magic != ZSPAGE_MAGIC)
- error(FATAL, "zspage magic incorrect: %x\n", zspage_s.magic);
+ if (VALID_MEMBER(zspage_huge))
+ zspage_shift = 1; // huge shift
+
+ class_idx = zspage_s.class >> zspage_shift;
+ zs_magic = zspage_s.magic >> zspage_shift;
+ if (zs_magic != ZSPAGE_MAGIC)
+ error(FATAL, "zspage magic incorrect: %x\n", zs_magic);
class = pool + OFFSET(zspoll_size_class);
class += (class_idx * sizeof(void *));
@@ -2794,8 +2800,13 @@ zram_object_addr(ulong pool, ulong handle, unsigned char *zram_buf)
}
pages[0] = page;
- readmem(page + OFFSET(page_freelist), KVADDR, &pages[1],
- sizeof(void *), "page_freelist", FAULT_ON_ERROR);
+ if (VALID_MEMBER(page_freelist)) {
+ readmem(page + OFFSET(page_freelist), KVADDR, &pages[1],
+ sizeof(void *), "page_freelist", FAULT_ON_ERROR);
+ } else {
+ readmem(page + OFFSET(page_index), KVADDR, &pages[1],
+ sizeof(void *), "page_index", FAULT_ON_ERROR);
+ }
sizes[0] = PAGESIZE() - off;
sizes[1] = size - sizes[0];
if (!is_page_ptr(pages[0], &paddr)) {
--
2.39.0
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
2 years
[PATCH] ppc64: do page traversal if vmemmap_list not populated
by Aditya Gupta
Currently 'crash-tool' fails on vmcore collected on upstream kernel on
PowerPC64 with the error:
crash: invalid kernel virtual address: 0 type: "first list entry
Presently the address translation for vmemmap addresses is done using
the vmemmap_list. But with the below commit in Linux, vmemmap_list can
be empty, in case of Radix MMU on PowerPC64
368a0590d954: (powerpc/book3s64/vmemmap: switch radix to use a
different vmemmap handling function)
In case vmemmap_list is empty, then it's head is NULL, which crash tries
to access and fails due to accessing NULL.
Instead of depending on 'vmemmap_list' for address translation for
vmemmap addresses, do a kernel pagetable walk to get the physical
address associated with given virtual address
Reviewed-by: Hari Bathini <hbathini(a)linux.ibm.com>
Signed-off-by: Aditya Gupta <adityag(a)linux.ibm.com>
---
Testing
=======
Git tree with patch applied:
https://github.com/adi-g15-ibm/crash/tree/bugzilla-203296-list-v1
This can be tested with '/proc/vmcore' as the vmcore, since makedumpfile
also fails in absence of 'vmemmap_list' in upstream linux
The fix for makedumpfile will also been sent to upstream
---
---
ppc64.c | 47 +++++++++++++++++++++++++++++++++--------------
1 file changed, 33 insertions(+), 14 deletions(-)
diff --git a/ppc64.c b/ppc64.c
index fc34006f4863..1e84c5f56773 100644
--- a/ppc64.c
+++ b/ppc64.c
@@ -1280,8 +1280,30 @@ void ppc64_vmemmap_init(void)
long backing_size, virt_addr_offset, phys_offset, list_offset;
ulong *vmemmap_list;
char *vmemmap_buf;
- struct machine_specific *ms;
-
+ struct machine_specific *ms = machdep->machspec;
+
+ ld = &list_data;
+ BZERO(ld, sizeof(struct list_data));
+
+ /*
+ * vmemmap_list is missing or set to 0 in the kernel would imply
+ * vmemmap region is mapped in the kernel pagetable. So, read vmemmap_list
+ * anyway and use the translation method accordingly.
+ */
+ readmem(symbol_value("vmemmap_list"), KVADDR, &ld->start, sizeof(void *),
+ "vmemmap_list", RETURN_ON_ERROR);
+ if (!ld->start) {
+ /*
+ * vmemmap_list is set to 0 or missing. Do kernel pagetable walk
+ * for vmemmamp address translation.
+ */
+ ms->vmemmap_list = NULL;
+ ms->vmemmap_cnt = 0;
+
+ machdep->flags |= VMEMMAP_AWARE;
+ return;
+ }
+
if (!(kernel_symbol_exists("vmemmap_list")) ||
!(kernel_symbol_exists("mmu_psize_defs")) ||
!(kernel_symbol_exists("mmu_vmemmap_psize")) ||
@@ -1293,8 +1315,6 @@ void ppc64_vmemmap_init(void)
!MEMBER_EXISTS("vmemmap_backing", "list"))
return;
- ms = machdep->machspec;
-
backing_size = STRUCT_SIZE("vmemmap_backing");
virt_addr_offset = MEMBER_OFFSET("vmemmap_backing", "virt_addr");
phys_offset = MEMBER_OFFSET("vmemmap_backing", "phys");
@@ -1313,14 +1333,8 @@ void ppc64_vmemmap_init(void)
ms->vmemmap_psize = 1 << shift;
- ld = &list_data;
- BZERO(ld, sizeof(struct list_data));
- if (!readmem(symbol_value("vmemmap_list"),
- KVADDR, &ld->start, sizeof(void *), "vmemmap_list",
- RETURN_ON_ERROR))
- return;
- ld->end = symbol_value("vmemmap_list");
- ld->list_head_offset = list_offset;
+ ld->end = symbol_value("vmemmap_list");
+ ld->list_head_offset = list_offset;
hq_open();
cnt = do_list(ld);
@@ -1366,7 +1380,7 @@ ppc64_vmemmap_to_phys(ulong kvaddr, physaddr_t *paddr, int verbose)
{
int i;
ulong offset;
- struct machine_specific *ms;
+ struct machine_specific *ms = machdep->machspec;
if (!(machdep->flags & VMEMMAP_AWARE)) {
/*
@@ -1386,7 +1400,12 @@ ppc64_vmemmap_to_phys(ulong kvaddr, physaddr_t *paddr, int verbose)
return FALSE;
}
- ms = machdep->machspec;
+ /**
+ * When vmemmap_list is not populated, kernel does the mapping in init_mm
+ * page table, so do a pagetable walk in kernel page table
+ */
+ if (!ms->vmemmap_list)
+ return ppc64_vtop_level4(kvaddr, (ulong *)vt->kernel_pgd[0], paddr, verbose);
for (i = 0; i < ms->vmemmap_cnt; i++) {
if ((kvaddr >= ms->vmemmap_list[i].virt) &&
--
2.41.0
2 years
Fix: move huge compressed obj from page to zspage
by 陈冠有
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
2 years
Re: [Crash-utility] [RFC PATCH v2 0/4] Improve stack unwind on ppc64
by lijiang
Hi, Aditya
Sorry for the late reply, and thank you for the update.
On Wed, Aug 9, 2023 at 4:38 AM <crash-utility-request(a)redhat.com> wrote:
> Date: Wed, 9 Aug 2023 02:03:17 +0530
> From: Aditya Gupta <adityag(a)linux.ibm.com>
> To: crash-utility(a)redhat.com
> Cc: Mahesh J Salgaonkar <mahesh(a)linux.ibm.com>, Sourabh Jain
> <sourabhjain(a)linux.ibm.com>, Hari Bathini <hbathini(a)linux.ibm.com>
> Subject: [Crash-utility] [RFC PATCH v2 0/4] Improve stack unwind on
> ppc64
> Message-ID: <20230808203321.241732-1-adityag(a)linux.ibm.com>
> Content-Type: text/plain; charset=UTF-8
>
> The Problem:
> ============
>
> Currently crash is unable to show function arguments and local variables,
> as
>
That's true, we have to calculate and infer their values from the
stack/registers, because they may be stored in registers or stack. This is
not friendly to most kernel developers and debuggers.
Anyway, this is a good point. If inline functions can also be displayed, it
would be better.
gdb can do. And functionality for moving between frames ('up'/'down') is not
> working in crash.
>
> Crash has 'gdb passthroughs' for things gdb can do, but the gdb
> passthroughs
> 'bt', 'frame', 'info locals', 'up', 'down' are not working either, due to
> gdb not getting the register values from `crash_target::fetch_registers`,
> which then uses `machdep->get_cpu_reg`, which is not implemented for PPC64
>
> Proposed Solution:
> ==================
>
> Fix the gdb passthroughs by implementing "machdep->get_cpu_reg" for PPC64.
> This way, "gdb mode in crash" will support this feature for both ELF and
> kdump-compressed vmcore formats, while "gdb" would only have supported ELF
> format
>
> Implications on Architectures:
> ====================================
>
> No architecture other than PPC64 has been affected, other than in case of
> 'frame' command
>
>
BTW: Can this feature be implemented on other architectures such as X86 64,
etc? Have you investigated?
> As mentioned in patch #2, since frame will not be prohibited, so it will
> print:
>
> crash> frame
> #0 <unavailable> in ?? ()
>
> Instead of before prohibited message:
>
> crash> frame
> crash: prohibited gdb command: frame
>
> On PPC64, the default mode ("crash mode") will not have ANY OTHER changes,
> other than 'frame' as mentioned above.
>
> Major change will be in 'gdb mode' on PPC64, that it will print the
> frames, and
> local variables, instead of failing with errors showing no frame, or
> showing
> that couldn't get PC
>
> Testing:
> ========
>
> Git tree with this patch series applied:
> https://github.com/adi-g15-ibm/crash/tree/stack-unwind-rfc2
>
> To test gdb passthroughs:
>
> crash> set gdb on
> gdb> thread 3 # or any other thread number to change context in gdb
> gdb> bt
> gdb> frame
> gdb> up
> gdb> down
> gdb> info locals
>
>
I did a simple test as below(kernel commit: 99d99825fc07):
gdb> info threads
Id Target Id Frame
1 CPU 0 <unavailable> in ?? ()
2 CPU 1
gdb> thread 2
[Switching to thread 2 (CPU 1)]
#0 0xc0000000002843f8 in crash_setup_regs (oldregs=<optimized out>,
newregs=0xc00000003dbd7958) at ./arch/powerpc/include/asm/kexec.h:69
69 ppc_save_regs(newregs);
gdb> bt
#0 0xc0000000002843f8 in crash_setup_regs (oldregs=<optimized out>,
newregs=0xc00000003dbd7958) at ./arch/powerpc/include/asm/kexec.h:69
#1 __crash_kexec (regs=<optimized out>) at kernel/kexec_core.c:1064
#2 0xc00000000014e018 in panic (fmt=0xc000000001443d80 "sysrq triggered
crash\n") at kernel/panic.c:359
#3 0xc0000000009b8978 in sysrq_handle_crash (key=<optimized out>) at
drivers/tty/sysrq.c:155
#4 0xc0000000009b946c in __handle_sysrq (key=key@entry=99,
check_mask=check_mask@entry=false) at drivers/tty/sysrq.c:602
#5 0xc0000000009b9ce8 in write_sysrq_trigger (file=<optimized out>,
buf=<optimized out>, count=2, ppos=<optimized out>) at
drivers/tty/sysrq.c:1163
#6 0xc0000000006919fc in pde_write (ppos=<optimized out>, count=<optimized
out>, buf=<optimized out>, file=<optimized out>, pde=0xc00000000556fcc0) at
fs/proc/inode.c:340
#7 proc_reg_write (file=<optimized out>, buf=<optimized out>,
count=<optimized out>, ppos=<optimized out>) at fs/proc/inode.c:352
#8 0xc0000000005b7cb8 in vfs_write (file=file@entry=0xc000000036fa5f00,
buf=buf@entry=0x10027835560 <error: Cannot access memory at address
0x10027835560>, count=count@entry=2, pos=pos@entry=0xc00000003dbd7de0) at
fs/read_write.c:582
#9 0xc0000000005b83a4 in ksys_write (fd=<optimized out>, buf=0x10027835560
<error: Cannot access memory at address 0x10027835560>, count=2) at
fs/read_write.c:637
#10 0xc000000000031454 in system_call_exception (regs=0xc00000003dbd7e80,
r0=<optimized out>) at arch/powerpc/kernel/syscall.c:153
#11 0xc00000000000cedc in system_call_vectored_common () at
arch/powerpc/kernel/interrupt_64.S:198
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
gdb> frame 7
#7 proc_reg_write (file=<optimized out>, buf=<optimized out>,
count=<optimized out>, ppos=<optimized out>) at fs/proc/inode.c:352
352 rv = pde_write(pde, file, buf, count, ppos);
gdb> info rv
gdb: gdb request failed: info rv
gdb>
Seems that the 'info locals' command is not working as expected. I haven't
investigated the details.
Known Issues:
> =============
>
> 1. In gdb mode, 'info threads' might hang for few seconds, and print only 2
> threads
>
Hmm, it only prints 2 threads, and one of which is unavailable on my side.
Can you try to dig into the details?
> 2. In gdb mode, 'bt' might fail to show backtrace in few vmcores collected
> from older kernels. This is a known issue due to register mismatch, and
> its fix has been merged upstream:
>
> Commit:
> https://github.com/torvalds/linux/commit/b684c09f09e7a6af3794d4233ef78581...
>
> TODO:
> =====
>
> 1. Introduce automatic thread selection in gdb mode, to select the crashing
> thread in gdb, eliminating the need to manually run "thread <id>" after
> switching to gdb mode.
>
> Changelog:
> ==========
>
> RFC V2:
> - removed patch implementing 'frame', 'up', 'down' in crash
> - updated the cover letter by removing the mention of those commands
> other
> than the respective gdb passthrough
>
>
In addition, the get_dumpfile_regs() is not invoked in the [patch 1], I
would suggest moving it into the [patch 2]. Just a glance, I haven't looked
at the patchset carefully.
Thanks.
Lianbo
Aditya Gupta (4):
> add generic get_dumpfile_regs to read registers
> ppc64: fix gdb passthrough by implementing machdep->get_cpu_reg
> remove 'frame' from prohibited commands list
> make cpu context change transparent to crash/gdb
>
> defs.h | 125 ++++++++++++++++++++++++++++++++++++++++++++++++
> gdb-10.2.patch | 28 +++++++++++
> gdb_interface.c | 2 +-
> kernel.c | 33 +++++++++++++
> ppc64.c | 105 ++++++++++++++++++++++++++++++++++++++--
> tools.c | 12 +++--
> 6 files changed, 298 insertions(+), 7 deletions(-)
>
> --
> 2.41.0
>
2 years
[PATCH] diskdump: fix read_diskdump() returns successfully for illegal 0-size page descriptors
by HATAYAMA Daisuke
read_diskdump() returns successfully for illegal 0-size page
descriptors. Page descriptors are illegal if their size member holds 0
because makedumpfile never puts 0 there because any data never result
in 0 byte by compression. If page descriptors hold 0 in size member,
it means the crash dump file is corrupted for some reason.
The root cause of this is that sanity check of function cache_page()
doesn't focus on such 0-size page descriptors. Then, the 0-size page
descriptor is passed to pread(), pread() immediately returns 0
successfully because read data is 0 byte, and then read_diskdump()
returns successfully.
To fix this issue, let the sanity check take into account such 0-size
page descriptors and read_diskdump() result in READ_ERROR.
Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)fujitsu.com>
---
diskdump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diskdump.c b/diskdump.c
index 2c284ff..2be7cc7 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -1210,7 +1210,7 @@ cache_page(physaddr_t paddr)
return ret;
/* sanity check */
- if (pd.size > block_size)
+ if (pd.size > block_size || !pd.size)
return READ_ERROR;
/* read page data */
--
2.25.1
2 years
[PATCH v1 00/10] add LoongArch64 platform support
by Ming Wang
This patch set are for Crash-utility tool, it make crash tool support on
loongarch64 architecture and the common commands(bt, p, rd, mod, log, set,
dis, and so on).
In the RFC discussed about the gdb version issue. See:
https://listman.redhat.com/archives/crash-utility/2023-July/010871.html
LoongArch64 need a gdb backport patch(gdb-10.2-loongarch.patch) and
it is integrated in the v1-0001-Add-LoongArch64-framework-code-support.patch
The patch sets were tested on a loongArch64 Loongson-3C5000 processor. Can
successfully enter the crash command line and support for common command.
...
KERNEL: vmlinux
DUMPFILE: /proc/kcore
CPUS: 16
DATE: Thu Jul 27 19:51:21 CST 2023
UPTIME: 06:35:11
LOAD AVERAGE: 0.15, 0.03, 0.01
TASKS: 257
NODENAME: localhost.localdomain
RELEASE: 5.10.0-60.102.0.128.oe2203.loongarch64
VERSION: #1 SMP Fri Jul 14 04:17:09 UTC 2023
MACHINE: loongarch64 (2200 Mhz)
MEMORY: 64 GB
PID: 2964
COMMAND: "crash"
TASK: 9000000098805500 [THREAD_INFO: 9000000094d48000]
CPU: 6
STATE: TASK_RUNNING (ACTIVE)
crash>
crash> dis -l start_kernel
/linux-loongarch64/init/main.c: 883
0x9000000001030818 <start_kernel>: 0x0141ee40
/linux-loongarch64/init/main.c: 879
0x900000000103081c <start_kernel+4>: 0x90000000
/linux-loongarch64/init/main.c: 883
0x9000000001030820 <start_kernel+8>: addu16i.d $zero, $t8, 8179(0x1ff3)
/linux-loongarch64/init/main.c: 879
...
About the LoongArch64 Architecture:
https://www.kernel.org/doc/html/latest/loongarch/index.html
Ming Wang (10):
Add LoongArch64 framework code support
LoongArch64: Make the crash tool successfully enter the crash command line
LoongArch64: Add 'pte' command support
LoongArch64: Add 'mach' command support
LoongArch64: Add 'bt' command support
LoongArch64: Add 'help -m/M' command support
LoongArch64: Add 'help -r' command support
LoongArch64: Add 'irq' command support
LoongArch64: Add "--kaslr" command line option support
LoongArch64: Add LoongArch64 architecture support information
Makefile | 9 +-
README | 4 +-
configure.c | 27 +-
crash.8 | 2 +-
defs.h | 185 +-
diskdump.c | 24 +-
gdb-10.2-loongarch.patch | 15206 +++++++++++++++++++++++++++++++++++++
help.c | 13 +-
lkcd_vmdump_v1.h | 2 +-
lkcd_vmdump_v2_v3.h | 5 +-
loongarch64.c | 1344 ++++
main.c | 3 +-
netdump.c | 27 +-
ramdump.c | 2 +
symbols.c | 33 +-
15 files changed, 16861 insertions(+), 25 deletions(-)
create mode 100644 gdb-10.2-loongarch.patch
create mode 100644 loongarch64.c
base-commit: 3253e5ac87c67dd7742e2b2bd9d912f21c1d2711
--
2.34.1
2 years