6:10 a.m.
Hi,hatayama
Please refer to the following for the exact kernel changes:
commit 34be98f4944f99076f049a6806fc5f5207a755d3
Author: Ard Biesheuvel <ard.biesheuvel(a)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).
However, this is not necessary, as:
* When an exception is taken from a task stack, we decrement the SP by
S_FRAME_SIZE and stash the exception registers before we compare the
SP against the task stack. In such cases, the SP must be at least
S_FRAME_SIZE below the limit, and can be safely masked to determine
whether the task stack is in use.
* When transitioning to an IRQ stack, we'll place a dummy frame onto the
IRQ stack before enabling asynchronous exceptions, or executing code
we expect to trigger faults. Thus, if an exception is taken from the
IRQ stack, the SP must be at least 16 bytes below the limit.
* We no longer mask the SP to find the thread_info, which is now found
via sp_el0. Note that historically, the offset was critical to ensure
that cpu_switch_to() found the correct stack for new threads that
hadn't yet executed ret_from_fork().
Given that, this initial offset serves no purpose, and can be removed.
This brings us in-line with other architectures (e.g. x86) which do not
rely on this masking.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[Mark: rebase, kill THREAD_START_SP, commit msg additions]
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Reviewed-by: Will Deacon <will.deacon(a)arm.com>
Tested-by: Laura Abbott <labbott(a)redhat.com>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: James Morse <james.morse(a)arm.com>
________________________________________
From: d.hatayama(a)fujitsu.com <d.hatayama(a)fujitsu.com>
Sent: Monday, April 6, 2020 12:32
To: 赵乾利
Cc: crash-utility(a)redhat.com <crash-utility(a)redhat.com>
Subject: RE: [External Mail]RE: zram decompress support for gcore/crash-utility
Zhao,
-----Original Message-----
From: 赵乾利 <zhaoqianli(a)xiaomi.com>
Sent: Wednesday, April 1, 2020 10:22 PM
To: Hatayama, Daisuke/畑山 大輔 <d.hatayama(a)fujitsu.com>
Cc: crash-utility(a)redhat.com <crash-utility(a)redhat.com>
<crash-utility(a)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(a)fujitsu.com <d.hatayama(a)fujitsu.com>
发送时间: 2020年4月1日 17:47
收件人: 赵乾利 <zhaoqianli(a)xiaomi.com>
抄送: crash-utility(a)redhat.com <crash-utility(a)redhat.com>
<crash-utility(a)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(a)redhat.com
> <crash-utility-bounces(a)redhat.com> On Behalf Of ?乾利
> Sent: Tuesday, March 31, 2020 9:49 AM
> To: crash-utility(a)redhat.com <crash-utility(a)redhat.com>
> <crash-utility(a)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(a)linaro.org
> <mailto:ard.biesheuvel@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(a)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!******/#
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
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!******/#