Re: [PATCH] remove struct zspage_5_17 and use union to resolve issue
by Lianbo Jiang
Hi, Chenguanyou
Thank you for the patch.
Can you post the v2 with plain text? Or did I miss anything?
Thanks
Lianbo
On 4/24/24 20:13, devel-request(a)lists.crash-utility.osci.io wrote:
> Date: Wed, 24 Apr 2024 17:23:55 +0800
> From: Guanyou Chen<chenguanyou9338(a)gmail.com>
> Subject: [Crash-utility] [PATCH] remove struct zspage_5_17 and use
> union to resolve issue
> To: Lianbo<lijiang(a)redhat.com>,devel(a)lists.crash-utility.osci.io,
> k-hagio-ab(a)nec.com
> Message-ID:
> <CAHS3RMVjQ7bBG4cnrdzswsAGrNeRW30AaPtVzXNJ3XHHyb+8+A(a)mail.gmail.com>
> Content-Type: multipart/mixed; boundary="00000000000072ca390616d43bfc"
>
> --00000000000072ca390616d43bfc
> Content-Type: multipart/alternative; boundary="00000000000072ca370616d43bfa"
>
> --00000000000072ca370616d43bfa
> Content-Type: text/plain; charset="UTF-8"
>
> Hi LianBo
>
> We don't need struct zspage_5_17.
>
> ---
> defs.h | 32 +++++++++++++++-----------------
> diskdump.c | 15 ++++++---------
> 2 files changed, 21 insertions(+), 26 deletions(-)
1 month, 2 weeks
Re: [PATCH v5 ] Adding the zram decompression algorithm "lzo-rle"
by Lianbo Jiang
Hi, Yulong
Thank you for the update.
The v5 looks good to me.
Applied:
https://github.com/crash-utility/crash/commit/a584e9752fb2198c7f6d0130d8a...
On 4/28/24 15:20, devel-request(a)lists.crash-utility.osci.io wrote:
> Date: Sun, 28 Apr 2024 07:20:01 +0000
> From: Yulong TANG 汤玉龙<yulong.tang(a)nio.com>
> Subject: [Crash-utility] [PATCH v5 ] Adding the zram decompression
> algorithm "lzo-rle"
> To:"devel(a)lists.crash-utility.osci.io"
> <devel(a)lists.crash-utility.osci.io>
> Message-ID: <BJSPR01MB0721C50C8B0ECF8126862965E914A(a)BJSPR01MB0721.CHN
> PR01.prod.partner.outlook.cn>
> Content-Type: multipart/mixed; boundary="_004_BJSPR01MB0721C50C8B0ECF
> 8126862965E914ABJSPR01MB0721CHNP_"
>
> --_004_BJSPR01MB0721C50C8B0ECF8126862965E914ABJSPR01MB0721CHNP_
> Content-Type: multipart/alternative;
> boundary="_000_BJSPR01MB0721C50C8B0ECF8126862965E914ABJSPR01MB0721CHNP_"
>
> --_000_BJSPR01MB0721C50C8B0ECF8126862965E914ABJSPR01MB0721CHNP_
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: base64
BTW: I got some encoding issues as below:
SW4gTGludXggNS4xLCB0aGUgWlJBTSBibG9jayBkcml2ZXIgaGFzIGNoYW5nZWQgaXRzIGRlZmF1
bHQgY29tcHJlc3NvciBmcm9tICJsem8iIHRvICJsem8tcmxlIiB0byBlbmhhbmNlIExaTyBjb21w
cmVzc2lvbiBzdXBwb3J0LiBIb3dldmVyLCBjcmFzaCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpbXBy
...
And it's not plain text...
Could you please check your email configuration? I haven't seen the similar issues from other people's emails. Just a guess.
Thanks
Lianbo
1 month, 3 weeks
[Question] crash-8.0.5 invalid to parse the assembly code by dis cmd for ARM64 crash dump
by qiwu.chen＠transsion.com
Dear sirs,
I found a bug for crash-8.0.5 that I failed to parse the assembly code by dis cmd for ARM64 crash dump:
$ crash vmlinux dump.202403061305 -d 1
KERNEL: vmlinux [TAINTED]
DUMPFILE: dump.202403061305 [PARTIAL DUMP]
CPUS: 4crash: get_cpus_online: online: 4
DATE: Wed Mar 6 21:04:30 CST 2024
UPTIME: 2135039823346 days, 00:18:07
LOAD AVERAGE: 0.32, 0.40, 0.17
TASKS: 93
NODENAME: benshushu
RELEASE: 5.15.0+
VERSION: #1 SMP Tue Mar 5 16:54:41 CST 2024
MACHINE: aarch64 (unknown Mhz)
MEMORY: 1 GB
PANIC: "Unable to handle kernel paging request at virtual address ffff800809102430"
PID: 494
COMMAND: "bash"
TASK: ffff000007d11a80 [THREAD_INFO: ffff000007d11a80]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 494 TASK: ffff000007d11a80 CPU: 0 COMMAND: "bash"
0: ffff80001022400c (crash_kexec)
#0 [ffff000007ce34d0] crash_kexec at ffff800010224008
#1 [ffff000007ce3570] die at ffff800010030038
#2 [ffff000007ce35e0] die_kernel_fault at ffff80001005d8e8
#3 [ffff000007ce3610] __do_kernel_fault at ffff80001005dbf4
#4 [ffff000007ce3650] do_bad_area at ffff80001005de14
#5 [ffff000007ce36b0] do_translation_fault at ffff800011172f84
#6 [ffff000007ce3700] do_mem_abort at ffff80001005e220
#7 [ffff000007ce3760] el1_abort at ffff800011162210
#8 [ffff000007ce3790] el1h_64_sync_handler at ffff80001116243c
#9 [ffff000007ce38f0] el1h_64_sync at ffff8000100111dc
......
crash> dis do_mem_abort
crash> dis -x ffff80001005e220 -r 8
0xffff80001005e184 <do_mem_abort>:
crash> dis do_mem_abort
0xffff80001005e184 <do_mem_abort>:
crash> dis do_translation_fault
0xffff800011172ed4 <do_translation_fault>:
There is no problem for crash-8.0.4:
crash> dis do_mem_abort
0xffff80001005e184 <do_mem_abort>: mov x9, x30
0xffff80001005e188 <do_mem_abort+4>: nop
0xffff80001005e18c <do_mem_abort+8>: stp x29, x30, [sp, #-96]!
0xffff80001005e190 <do_mem_abort+12>: mov x29, sp
......
There must be some change corrupted the ARM64 dis function. Please help look at the issue.
Thanks
1 month, 3 weeks
[Question] About BITS_PER_LONG
by Guanyou Chen
Hi Tao, Lianbo
BITS_PER_LONG should equals 32 when on host x86_64 build target arm ?
diff --git a/defs.h b/defs.h
index 01f316e..4d8ebc9 100644
--- a/defs.h
+++ b/defs.h
@@ -4842,7 +4842,11 @@ struct machine_specific {
#define UNINITIALIZED (BADVAL)
#define BITS_PER_BYTE (8)
-#define BITS_PER_LONG (BITS_PER_BYTE * sizeof(long))
+#ifdef _64BIT_
+#define BITS_PER_LONG (64)
+#else
+#define BITS_PER_LONG (32)
+#endif
1 month, 3 weeks
[PATCH] remove struct zspage_5_17 and use union to resolve issue
by Guanyou Chen
Hi LianBo
We don't need struct zspage_5_17.
---
defs.h | 32 +++++++++++++++-----------------
diskdump.c | 15 ++++++---------
2 files changed, 21 insertions(+), 26 deletions(-)
diff --git a/defs.h b/defs.h
index 3cb8e63..01f316e 100644
--- a/defs.h
+++ b/defs.h
@@ -7407,28 +7407,26 @@ ulong try_zram_decompress(ulonglong pte_val,
unsigned char *buf, ulong len, ulon
#define SECTORS_PER_PAGE (1 << SECTORS_PER_PAGE_SHIFT)
struct zspage {
- struct {
- unsigned int fullness : 2;
- unsigned int class : 9;
- unsigned int isolated : 3;
- unsigned int magic : 8;
+ union {
+ unsigned int flag_bits;
+ struct {
+ unsigned int fullness : 2;
+ unsigned int class : 9;
+ unsigned int isolated : 3;
+ unsigned int magic : 8;
+ } v0;
+ struct {
+ unsigned int huge : 1;
+ unsigned int fullness : 2;
+ unsigned int class : 9;
+ unsigned int isolated : 3;
+ unsigned int magic : 8;
+ } v5_17;
};
unsigned int inuse;
unsigned int freeobj;
};
-struct zspage_5_17 {
- struct {
- unsigned int huge : 1;
- unsigned int fullness : 2;
- unsigned int class : 9;
- unsigned int isolated : 3;
- unsigned int magic : 8;
- };
- unsigned int inuse;
- unsigned int freeobj;
-};
-
/*
* makedumpfile.c
*/
diff --git a/diskdump.c b/diskdump.c
index 3ae7bf2..a928a0e 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -2819,7 +2819,6 @@ zram_object_addr(ulong pool, ulong handle, unsigned
char *zram_buf)
{
ulong obj, off, class, page, zspage;
struct zspage zspage_s;
- struct zspage_5_17 zspage_5_17_s;
physaddr_t paddr;
unsigned int obj_idx, class_idx, size;
ulong pages[2], sizes[2];
@@ -2833,15 +2832,13 @@ zram_object_addr(ulong pool, ulong handle, unsigned
char *zram_buf)
readmem(page + OFFSET(page_private), KVADDR, &zspage,
sizeof(void *), "page_private", FAULT_ON_ERROR);
+ readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "zspage",
FAULT_ON_ERROR);
if (VALID_MEMBER(zspage_huge)) {
- readmem(zspage, KVADDR, &zspage_5_17_s,
- sizeof(struct zspage_5_17), "zspage_5_17", FAULT_ON_ERROR);
- class_idx = zspage_5_17_s.class;
- zs_magic = zspage_5_17_s.magic;
+ class_idx = zspage_s.v5_17.class;
+ zs_magic = zspage_s.v5_17.magic;
} else {
- readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "zspage",
FAULT_ON_ERROR);
- class_idx = zspage_s.class;
- zs_magic = zspage_s.magic;
+ class_idx = zspage_s.v0.class;
+ zs_magic = zspage_s.v0.magic;
}
if (zs_magic != ZSPAGE_MAGIC)
@@ -2887,7 +2884,7 @@ zram_object_addr(ulong pool, ulong handle, unsigned
char *zram_buf)
out:
if (VALID_MEMBER(zspage_huge)) {
- if (!zspage_5_17_s.huge)
+ if (!zspage_s.v5_17.huge)
return (zram_buf + ZS_HANDLE_SIZE);
} else {
readmem(page, KVADDR, &obj, sizeof(void *), "page flags",
FAULT_ON_ERROR);
--
2.39.0
1 month, 3 weeks
[PATCH] arm64: section_size_bits compatible with macro definitions
by Guanyou Chen
Hi Kazu,
Compatible with google android GKI changes,
SECTION_SIZE_BITS = 27 when defined 4K_PAGES or 16K_PAGES.
SECTION_SIZE_BITS = 29 when defined 64K_PAGES.
Link:
https://lore.kernel.org/lkml/15cf9a2359197fee0168f820c5c904650d07939e.161...
Link:
https://lore.kernel.org/all/43843c5e092bfe3ec4c41e3c8c78a7ee35b69bb0.1611...
See:
https://cs.android.com/android/_/android/kernel/common/+/673e9ab6b64f9811...
Before android-12-gki:
crash> help -m | grep section_size_bits
section_size_bits: 30
The first PFN error, the physical address should be 0x40000000.
crash> kmem -p
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffffff06e00000 200000000 ffffff80edf4fa12 ffffffff070f3640 1
4000000000002000 private
After android-12-gki:
crash> help -m | grep section
section_size_bits: 27
crash> kmem -p
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
fffffffeffe00000 40000000 0 0 1 1000 reserved
Signed-off-by: chenguanyou <chenguanyou(a)xiaomi.com>
---
arm64.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arm64.c b/arm64.c
index e36c723..50e22ea 100644
--- a/arm64.c
+++ b/arm64.c
@@ -1629,7 +1629,16 @@ arm64_get_section_size_bits(void)
if ((ret = get_kernel_config("CONFIG_HOTPLUG_SIZE_BITS",
&string)) == IKCONFIG_STR)
machdep->section_size_bits = atol(string);
}
- }
+
+ // arm64: reduce section size for sparsemem
+ if ((ret = get_kernel_config("CONFIG_ARM64_4K_PAGES", NULL)) ==
IKCONFIG_Y
+ || (ret = get_kernel_config("CONFIG_ARM64_16K_PAGES",
NULL)) == IKCONFIG_Y)
+ machdep->section_size_bits = _SECTION_SIZE_BITS_5_12;
+ // arm64/sparsemem: reduce SECTION_SIZE_BITS
+ else if ((ret = get_kernel_config("CONFIG_ARM64_64K_PAGES", NULL))
== IKCONFIG_Y)
+ machdep->section_size_bits = _SECTION_SIZE_BITS_5_12_64K;
+
+ }
if (CRASHDEBUG(1))
fprintf(fp, "SECTION_SIZE_BITS: %ld\n", machdep->section_size_bits);
--
2.39.0
Thanks,
Guanyou.Chen
1 month, 3 weeks