[Crash-utility] 答复: [External Mail]Re: zram decompress support for gcore/crash-utility

[赵乾利]

Hi,?

I think gcore or other client,no need to understand what is zram and just call readmem to get the data.so i encapsulate try_zram_decompress to readmem,gcore just calling readmem can get right data.It will have better encapsulation?,If one day the kernel provides other ram swap,Do we need to add changes in gcore synchronously??

If it's just for historical reasons and the problem has been solved,keep this code is unnecessary,it's just my consideration?.

The first patch I made was calling try_zram_decompress in gcore.You can also think about this patch?.


Thanks.


________________________________
From: d.hatayama at fujitsu.com <d.hatayama at fujitsu.com>
Sent: Wednesday, April 15, 2020 20:25
To: 赵乾利; Dave Anderson
Cc: Discussion list for crash utility usage, maintenance and development
Subject: Re: 答复: [External Mail]Re: [Crash-utility] zram decompress support for gcore/crash-utility

Hi,

?Hi,Hatayama?

Since zram page not a existing page?,so we can't use vtop find exactly physical address,so gcore have  to make a little change for this.gcore patch i've already sent in previous mail
Please don't remove uvtop_quiet(), which is necessary. The reason is to avoid some bug in crash utility in the past as written in the comment in uvtop_quiet().

Looking at the following stanza, the necessary change is to add a call of try_zram_decompress() when uvtop_quiet() returns false but paddr is non-zero.

   https://github.com/crash-utility/crash/commit/b12bdd36cf7caad24957c0b8c030001321ab2df4#diff-997c8aaa6bf9a3d9f77e5cab843cd9a6R2290

defs.h belongs to crash utility. Please don't post change of defs.h to crash gcore command.


I've answered your question in the previous email about exactly kernel commit in aarch64 stack,please refer to below change
The latest two changes are attached?,please review.
Thanks. I'll review this later.

commit 34be98f4944f99076f049a6806fc5f5207a755d3
Author: Ard Biesheuvel <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).

    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 at linaro.org>
    [Mark: rebase, kill THREAD_START_SP, commit msg additions]
    Signed-off-by: Mark Rutland <mark.rutland at arm.com>
    Reviewed-by: Will Deacon <will.deacon at arm.com>
    Tested-by: Laura Abbott <labbott at redhat.com>
    Cc: Catalin Marinas <catalin.marinas at arm.com>
    Cc: James Morse <james.morse at arm.com>?

#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!******/#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20200415/6ae27540/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcore-zram0415.zip
Type: application/zip
Size: 955 bytes
Desc: gcore-zram0415.zip
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20200415/6ae27540/attachment.zip>