[Crash-utility] 答复: [External Mail]Re: zram decompress support for gcore/crash-utility
Dave Anderson
anderson at redhat.com
Thu Apr 2 16:16:10 UTC 2020
----- Original Message -----
> Hi,Dave & hatayama
>
> I made two patchs in crash-utility and gcore to support zram decompress
> 1.In crash-utility,I add patch in readmem to support zram decompression,
> readmem interface automatically recognizes and decompresses zram data.
> There are some limitations to zram support,only support lzo decompress,kernel
> support lzo,lz4,lz4hc,842,zstd,but lzo is default.
>
> use "rd" command also read data even if mapping to zram
> [without patch]
> crash> rd 144fc000 2
> rd: invalid user virtual address: 144fc000 type: "64-bit UVADDR"
> [with patch]
> crash> rd 144fc000 2
> 144fc000: 06ecdc6b06ecb280 06f027f906eebebe ....k........'..
With respect to the crash utility patch:
Apparently you wrote this patch to only support ARM64? Here's what happens on an x86_64:
$ patch -p1 < $bos/0001-support-zram-decompress-in-readmem.patch
patching file defs.h
Hunk #5 succeeded at 5304 (offset 2 lines).
patching file memory.c
$ make warn
... [ cut ] ...
cc -c -g -DX86_64 -DLZO -DSNAPPY -DGDB_7_6 memory.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
In file included from memory.c:19:0:
memory.c: In function 'zram_object_addr':
defs.h:5310:27: error: 'PHYS_MASK_SHIFT' undeclared (first use in this function)
#define _PFN_BITS (PHYS_MASK_SHIFT - PAGESHIFT())
^
defs.h:5311:43: note: in expansion of macro '_PFN_BITS'
#define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
^
memory.c:19838:27: note: in expansion of macro 'OBJ_INDEX_BITS'
page = pfn_to_map(obj >> OBJ_INDEX_BITS);
^
defs.h:5310:27: note: each undeclared identifier is reported only once for each function it appears in
#define _PFN_BITS (PHYS_MASK_SHIFT - PAGESHIFT())
^
defs.h:5311:43: note: in expansion of macro '_PFN_BITS'
#define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
^
memory.c:19838:27: note: in expansion of macro 'OBJ_INDEX_BITS'
page = pfn_to_map(obj >> OBJ_INDEX_BITS);
^
memory.c: In function 'try_zram_decompress':
memory.c:19940:16: error: 'PTE_VALID' undeclared (first use in this function)
if (pte_val & PTE_VALID)
^
memory.c:19932:8: warning: unused variable 'ret' [-Wunused-variable]
ulong ret = 0;
^
make[4]: *** [memory.o] Error 1
make[3]: *** [gdb] Error 2
make[2]: *** [rebuild] Error 2
make[1]: *** [gdb_merge] Error 2
make: *** [warn] Error 2
$
So that's a non-starter. If it can't be made architecture-neutral, then at
least the other major architectures need to be supported. At a minimum all
architectures need to be able to be compiled with LZO enabled.
If you can do that, other suggestions I have for the patch are:
(1) Move all the new offset_table entries to the end of the structure to prevent
the breakage of previously-compiled extension modules that use OFFSET().
(2) Move the new LZO specific functions to diskdump.c, which is the only C file
that is set up to deal with LZO being #define'd on the fly with "make lzo".
(3) Create a dummy try_zram_decompress() function in diskdump.c that just
returns 0. Put it outside of the LZO function block, e.g.:
#ifdef LZO
zram_object_addr(args... )
...
lookup_swap_cache(args...)
...
try_zram_decompress(args...)
...
#else
try_zram_decompress(args...) { return 0; }
#endif
Alternatively, you could create a try_zram_decompress() macro in defs.h the same way.
(4) Remove the #ifdef/#endif LZO section of readmem().
(5) PLEASE do not make all the white-space changes in memory.c. It's annoying
to have to review the patch when it's cluttered with changes that are
irrelevant to the task at hand.
Thanks,
Dave
>
> 2.In gcore, I have to make a small change ,change parameter of readmem from
> PHYADDR to UVADDR, other work will be done by crash
>
> Please help review.
> Thanks
>
> -----邮件原件-----
> 发件人: Dave Anderson <anderson at redhat.com>
> 发送时间: 2020年4月2日 0:29
> 收件人: 赵乾利 <zhaoqianli at xiaomi.com>
> 抄送: d hatayama <d.hatayama at fujitsu.com>; Discussion list for crash utility
> usage, maintenance and development <crash-utility at redhat.com>
> 主题: Re: [External Mail]Re: [Crash-utility] zram decompress support for
> gcore/crash-utility
>
>
>
> ----- Original Message -----
> > Hi,Dave
> > Zram is a virtual device,it simulated as a block device,it's part of
> > memroy/ramdump,just enable CONFIG_ZRAM,no other settings needed.
> > you can refer to drivers/block/zram/zram_drv.c driver calling
> > zram_meta_alloc to alloc memory from RAM.
> >
> > We want to be able to access these zram page like a normal page.
>
> I understand all that. I'm just curious how makedumpfile will handle/filter
> the physical RAM pages that make up the zram block device.
>
> Anyway, send a patch and I'll take a look.
>
> Dave
>
>
> >
> > ________________________________________
> > From: Dave Anderson <anderson at redhat.com>
> > Sent: Wednesday, April 1, 2020 23:24
> > To: 赵乾利
> > Cc: d hatayama; Discussion list for crash utility usage, maintenance
> > and development
> > Subject: Re: [External Mail]Re: [Crash-utility] zram decompress
> > support for gcore/crash-utility
> >
> > ----- Original Message -----
> > > Hi,Dave
> > > zram is same with other swap device,but every swaped page will be
> > > compressed then saved to another memory address.
> > > The process is same with the common swap device,non-swap just a
> > > normal user address,pgd and mmu will translate to phy address
> > >
> > > please refer to below information:
> > > crash> vm -p
> > > PID: 1565 TASK: ffffffe1fce32d00 CPU: 7 COMMAND: "system_server"
> > > MM PGD RSS TOTAL_VM
> > > ffffffe264431c00 ffffffe1f54ad000 528472k 9780384k
> > > VMA START END FLAGS FILE
> > > ffffffe0ea401300 12c00000 12e00000 100073
> > > VIRTUAL PHYSICAL
> > > ...
> > > 144fc000 SWAP: /dev/block/zram0 OFFSET: 236750
> > > ...
> > > 1738e000 SWAP: /dev/block/zram0 OFFSET: 73426
> > > 1738f000 21aa2c000
> > > 17390000 1c3308000
> > > 17391000 SWAP: /dev/block/zram0 OFFSET: 73431
> > > 17392000 19c162000
> > > 17393000 19c132000
> > > 17394000 SWAP: /dev/block/zram0 OFFSET: 234576
> > > 17395000 19c369000
> > > 17396000 20b35c000
> > > 17397000 18011e000
> > > 17398000 SWAP: /dev/block/zram0 OFFSET: 73433
> > > 17399000 1dc3d2000
> > > 1739a000 1bc59f000
> > > 1739b000 SWAP: /dev/block/zram0 OFFSET: 73437
> > >
> > >
> > > crash> vtop -c 1565 144fc000
> > > VIRTUAL PHYSICAL
> > > 144fc000 (not mapped)
> > >
> > > PAGE DIRECTORY: ffffffe1f54ad000
> > > PGD: ffffffe1f54ad000 => 1f54ab003
> > > PMD: ffffffe1f54ab510 => 1f43b8003
> > > PTE: ffffffe1f43b87e0 => 39cce00
> > >
> > > PTE SWAP OFFSET
> > > 39cce00 /dev/block/zram0 236750
> > >
> > > VMA START END FLAGS FILE
> > > ffffffe148bafe40 144c0000 14540000 100073
> > >
> > > SWAP: /dev/block/zram0 OFFSET: 236750
> >
> > Ok, so with respect to user-space virtual addresses, there is nothing
> > other than handling zram swap-backed memory.
> >
> > So what you're proposing is that when reading user-space memory that
> > happens to be backed-up on a zram swap device, then the user data
> > could alternatively be read from the zram swap device, and presented
> > as if it were present in physical memory?
> >
> > Are the physical RAM pages that make up the contents of a zram device
> > collected with a typical filtered compressed kdump? If not, what
> > makedumpfile -d flag is required for them to be captured?
> >
> > Dave
> >
> >
> > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部
> > 或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> > 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