[Crash-utility] zram decompress support for gcore/crash-utility

d.hatayama at fujitsu.com d.hatayama at fujitsu.com
Wed Apr 1 09:47:05 UTC 2020


Zhan,

It looks to me that 0002-gcore-ARM-ARM64-reserved-8-16-byte-in-the-top-of-sta.patch is independent
of the ZRAM support. Without the patch, how does gcore behave? Fai or succeed? If gcore fails, could you
show me a log indicating how gcore command fails?

> -----Original Message-----
> From: crash-utility-bounces at redhat.com <crash-utility-bounces at redhat.com> On Behalf Of ?乾利
> Sent: Tuesday, March 31, 2020 9:49 AM
> To: crash-utility at redhat.com <crash-utility at redhat.com> <crash-utility at redhat.com>
> Subject: [Crash-utility] zram decompress support for gcore/crash-utility
> 
> Hello list,
> 
> 
> 
> When i try to use gcore to parse coredump from fulldump,I got below issue that make the coredump unavailable.
> 
> 1.     Zram is very common feature,in current android system supports zram swap,but gcore/crash-utility does not
> support,even zram swap can decoded from ram,many page fault due to this reason.
> 
> I added zram decompress feature to gcore,and i’m also considering wheather support zram in crash-utility,but for this
> feature,i have to add miniLZO to codebase, I'm not sure if it's acceptable,plase help give some advice.
> 
> miniLZO :miniLZO is a very lightweight subset of the LZO library,Distributed under the terms of the GNU General Public
> License <http://www.oberhumer.com/opensource/gpl.html>  (GPL v2+).
> 
> http://www.oberhumer.com/opensource/lzo/ <http://www.oberhumer.com/opensource/lzo/>
> 
> 
> 
> This change is a bit big,I attached it to the mail,if attachment is not available,you can also see these patch in github:
> https://github.com/zhaoqianli0202/crash-gcore/commits/upstream
> <https://github.com/zhaoqianli0202/crash-gcore/commits/upstream>
> 
> Please review.
> 
> 
> 
> 2.     For historical reasons,kernel reserved top 8/16 bytes of stacks,but after kernel-4.14, this reservation was
> cancelled,so gcore needs to improve compatibility.
> 
> kernel change as below:
> 
> commit 34be98f4944f99076f049a6806fc5f5207a755d3
> 
> Author: Ard Biesheuvel <ard.biesheuvel at linaro.org <mailto:ard.biesheuvel at linaro.org> >
> 
> Date:   Thu Jul 20 17:15:45 2017 +0100
> 
> 
> 
>     arm64: kernel: remove {THREAD,IRQ_STACK}_START_SP
> 
> 
> 
>     For historical reasons, we leave the top 16 bytes of our task and IRQ
> 
>     stacks unused, a practice used to ensure that the SP can always be
> 
>     masked to find the base of the current stack (historically, where
> 
>     thread_info could be found).™
> 
> ====
> 
> Patch for this issue:
> 
> commit d1031df4617351a58b8edfb0121c306baaa34f9d
> 
> Author: zhaoqianli <zhaoqianli at xiaomi.com>
> 
> Date:   Mon Mar 30 12:07:02 2020 +0800
> 
> 
> 
>     gcore: ARM/ARM64 reserved 8/16 byte in the top of stacks before 4.14,
> 
>     but this reservation was removed after 4.14
> 
> Without this patch,gcore counld't parse full callstack in version after 4.14
> 
> 
> 
> diff --git a/gcore.c b/gcore.c
> 
> index f75701d..f6e1787 100644
> 
> --- a/gcore.c
> 
> +++ b/gcore.c
> 
> @@ -558,4 +558,16 @@ static void gcore_machdep_init(void)
> 
> 
> 
>         if (!gcore_arch_vsyscall_has_vm_alwaysdump_flag())
> 
>                 gcore_machdep->vm_alwaysdump = 0x00000000;
> 
> +
> 
> +#if defined(ARM) || defined(ARM64)
> 
> +#ifdef ARM
> 
> +#define STACK_RESERVE_SIZE 8
> 
> +#else
> 
> +#define STACK_RESERVE_SIZE 16
> 
> +#endif
> 
> +       if (THIS_KERNEL_VERSION >= LINUX(4,14,0))
> 
> +               gcore_machdep->stack_reserve = 0;
> 
> +       else
> 
> +               gcore_machdep->stack_reserve = STACK_RESERVE_SIZE;
> 
> +#endif
> 
> }
> 
> diff --git a/libgcore/gcore_arm.c b/libgcore/gcore_arm.c
> 
> index 891d01e..c8aefdf 100644
> 
> --- a/libgcore/gcore_arm.c
> 
> +++ b/libgcore/gcore_arm.c
> 
> @@ -29,7 +29,7 @@ static int gpr_get(struct task_context *target,
> 
> 
> 
>         BZERO(regs, sizeof(*regs));
> 
> 
> 
> -       readmem(machdep->get_stacktop(target->task) - 8 - SIZE(pt_regs), KVADDR,
> 
> +       readmem(machdep->get_stacktop(target->task) - gcore_machdep->stack_reserve - SIZE(pt_regs), KVADDR,
> 
>                 regs, SIZE(pt_regs), "genregs_get: pt_regs",
> 
>                 gcore_verbose_error_handle());
> 
> 
> 
> diff --git a/libgcore/gcore_arm64.c b/libgcore/gcore_arm64.c
> 
> index 3257389..ed3fdc8 100644
> 
> --- a/libgcore/gcore_arm64.c
> 
> +++ b/libgcore/gcore_arm64.c
> 
> @@ -28,7 +28,7 @@ static int gpr_get(struct task_context *target,
> 
> 
> 
>         BZERO(regs, sizeof(*regs));
> 
> 
> 
> -       readmem(machdep->get_stacktop(target->task) - 16 - SIZE(pt_regs), KVADDR,
> 
> +       readmem(machdep->get_stacktop(target->task) - gcore_machdep->stack_reserve - SIZE(pt_regs), KVADDR,
> 
>                 regs, sizeof(struct user_pt_regs), "gpr_get: user_pt_regs",
> 
>                 gcore_verbose_error_handle());
> 
> 
> 
> @@ -124,7 +124,7 @@ static int compat_gpr_get(struct task_context *target,
> 
>         BZERO(&pt_regs, sizeof(pt_regs));
> 
>         BZERO(regs, sizeof(*regs));
> 
> 
> 
> -       readmem(machdep->get_stacktop(target->task) - 16 - SIZE(pt_regs), KVADDR,
> 
> +       readmem(machdep->get_stacktop(target->task) - gcore_machdep->stack_reserve - SIZE(pt_regs), KVADDR,
> 
>                 &pt_regs, sizeof(struct pt_regs), "compat_gpr_get: pt_regs",
> 
>                 gcore_verbose_error_handle());
> 
> 
> 
> diff --git a/libgcore/gcore_defs.h b/libgcore/gcore_defs.h
> 
> index b0f5603..f31036c 100644
> 
> --- a/libgcore/gcore_defs.h
> 
> +++ b/libgcore/gcore_defs.h
> 
> @@ -1177,6 +1177,7 @@ extern struct gcore_size_table gcore_size_table;
> 
> struct gcore_machdep_table
> 
> {
> 
>         ulong vm_alwaysdump;
> 
> +       uint8_t stack_reserve;
> 
> };
> 
> #/******本邮件及其附件含有小米公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式
> 使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知
> 发件人并删除本邮件! 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!******/#




More information about the Crash-utility mailing list