[Crash-utility] [External Mail]RE: zram decompress support for gcore/crash-utility
d.hatayama at fujitsu.com
d.hatayama at fujitsu.com
Mon Apr 6 04:32:12 UTC 2020
Zhao,
> -----Original Message-----
> From: 赵乾利 <zhaoqianli at xiaomi.com>
> Sent: Wednesday, April 1, 2020 10:22 PM
> To: Hatayama, Daisuke/畑山 大輔 <d.hatayama at fujitsu.com>
> Cc: crash-utility at redhat.com <crash-utility at redhat.com> <crash-utility at redhat.com>
> Subject: 答复: [External Mail]RE: zram decompress support for gcore/crash-utility
>
> Hi,hatayama
>
> I just porting zram support into crash-utility,in this way,gcore need calling zram decompress(try_zram_decompress)
> function in gcore.
> integrate zram decompress to readmem is a good suggestion,I'm working on it.
>
> About 0002-gcore-ARM-ARM64-reserved-8-16-byte-in-the-top-of-sta.patch,it's a completely independent
> patch,without this patch,the coredump register will be wrong/dislocation, so that gdb cannot parse out the complete call
> stack.
Thanks for your explanation. I will write this in the commit description.
Could you also tell me the exact commit in Linux kernel that made the corresponding change?
> You can see blow:
> [Without patch]
> (gdb) bt
> #0 android::Mutex::lock (this=<optimized out>) at system/core/libutils/include/utils/Mutex.h:183
> #1 android::Looper::pollInner (this=0x704ad1c590 <epoll_wait(int, epoll_event*, int, int)>, timeoutMillis=1291145664)
> at system/core/libutils/Looper.cpp:243
> #2 0xbc5e696a00000018 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> (gdb) info reg
> x0 0xffffff801998bff0 -549326372880
> x1 0xffffffa6d3e83848 -382991845304
> x2 0x34 52
> x3 0x7fdb6d8f90 549142237072
> x4 0x10 16
> x5 0x74a5 29861
> x6 0x0 0
> x7 0x8 8
> x8 0x704e33a000 482348343296
> x9 0xbf815ee 200807918
> x10 0x16 22
> x11 0xebabf645f5e97f31 -1464806473440067791
> x12 0x1 1
> x13 0xc0 192
> x14 0x20daea4ae8 141111741160
> x15 0x115 277
> x16 0x1080400222a3e010 1189020679541088272
> x17 0x40 64
> x18 0x704a9fcd70 482288323952
> x19 0x704ad1c590 482291598736
> x20 0x704e01c000 482345074688
> x21 0x704cf551c0 482327482816
> x22 0x704cf55268 482327482984
> x23 0x74a5 29861
> x24 0x74a5 29861
> x25 0x704cf551c0 482327482816
> x26 0x7fffffff 2147483647
> x27 0x704d0aa020 482328879136
> x28 0x704cfc8840 482327955520
> x29 0x704407b8 1883506616
> x30 0x70435dc8 1883463112
> sp 0x7fdb6d90f0 0x7fdb6d90f0
> pc 0x704a9f80c0 0x704a9f80c0 <android::Looper::pollInner(int)+148>
> cpsr 0xdb6d8f50 -613576880
> fpsr 0x17 23
> fpcr 0x0 0
>
> [With patch]
> (gdb) bt
> #0 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
> #1 0x000000704a9f80c0 in android::Looper::pollInner (this=0x704cf551c0, timeoutMillis=29861) at
> system/core/libutils/Looper.cpp:237
> #2 0x000000704a9f7f90 in android::Looper::pollOnce (this=0x704cf551c0, timeoutMillis=29861, outFd=0x0,
> outEvents=0x0, outData=0x0) at system/core/libutils/Looper.cpp:205
> #3 0x000000704c4530f4 in android::Looper::pollOnce (this=0x34, timeoutMillis=-613576816) at
> system/core/libutils/include/utils/Looper.h:267
> #4 android::NativeMessageQueue::pollOnce (this=<optimized out>, env=0x704cf5db80, pollObj=<optimized out>,
> timeoutMillis=-613576816)
> at frameworks/base/core/jni/android_os_MessageQueue.cpp:110
> #5 android::android_os_MessageQueue_nativePollOnce (env=0x704cf5db80, obj=<optimized out>, ptr=<optimized
> out>, timeoutMillis=-613576816)
> at frameworks/base/core/jni/android_os_MessageQueue.cpp:191
> #6 0x0000000073749590 in ?? ()
>
> (gdb) info registers
> x0 0x34 52
> x1 0x7fdb6d8f90 549142237072
> x2 0x10 16
> x3 0x74a5 29861
> x4 0x0 0
> x5 0x8 8
> x6 0x704e33a000 482348343296
> x7 0xbf815ee 200807918
> x8 0x16 22
> x9 0xebabf645f5e97f31 -1464806473440067791
> x10 0x1 1
> x11 0xc0 192
> x12 0x20daea4ae8 141111741160
> x13 0x115 277
> x14 0x1080400222a3e010 1189020679541088272
> x15 0x40 64
> x16 0x704a9fcd70 482288323952
> x17 0x704ad1c590 482291598736
> x18 0x704e01c000 482345074688
> x19 0x704cf551c0 482327482816
> x20 0x704cf55268 482327482984
> x21 0x74a5 29861
> x22 0x74a5 29861
> x23 0x704cf551c0 482327482816
> x24 0x7fffffff 2147483647
> x25 0x704d0aa020 482328879136
> x26 0x704cfc8840 482327955520
> x27 0x704407b8 1883506616
> x28 0x70435dc8 1883463112
> x29 0x7fdb6d90f0 549142237424
> x30 0x704a9f80c0 482288304320
> sp 0x7fdb6d8f50 0x7fdb6d8f50
> pc 0x704ad5c098 0x704ad5c098 <__epoll_pwait+8>
> cpsr 0x60001000 1610616832
> fpsr 0x17 23
> fpcr 0x0 0
>
> -----邮件原件-----
> 发件人: d.hatayama at fujitsu.com <d.hatayama at fujitsu.com>
> 发送时间: 2020年4月1日 17:47
> 收件人: 赵乾利 <zhaoqianli at xiaomi.com>
> 抄送: crash-utility at redhat.com <crash-utility at redhat.com> <crash-utility at redhat.com>
> 主题: [External Mail]RE: zram decompress support for gcore/crash-utility
>
> 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!******/#
> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式
> 使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知
> 发件人并删除本邮件！ 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