----- Original Message ----- 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

----- Original Message ----- 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

----- Original Message ----- 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

----- Original Message ----- The patch does compile cleanly, although I haven't tried compiling it on an s390x, but I'll do that soon. A couple issues with the patch: + if (!strncmp(name, "lzo", strlen("lzo"))) { + lzo_init(); + decompressor = (void *)lzo1x_decompress_safe; + } else {//todo,support more compressor + error(WARNING, "Only support lzo compressor\n"); + return 0; + } lzo_init() will have already been called by is_diskdump() here during session initialization if the dumpfile is a compressed kdump: #ifdef LZO if (lzo_init() == LZO_E_OK) dd->flags |= LZO_SUPPORTED; #endif So try_zram_decompress() should check if (dd->flags & LZO_SUPPORTED) has been set before calling lzo_init() again. And while I don't object to exporting swap_info_init(), I do have a problem with pfn_to_map(): +void swap_info_init(void); +ulong pfn_to_map(ulong); ... + obj >>= OBJ_TAG_BITS; + page = pfn_to_map(obj >> OBJ_INDEX_BITS); + obj_idx = (obj & OBJ_INDEX_MASK); The pfn_to_map() function is only relevant if the kernel is configured with SPARSEMEM. I don't see why the exported phys_to_page() function could not be used here? Thanks, Dave

patch update Found a better way translate pfn to page,PTOB. Besides,fix a issue with low probability of decompression failure ________________________________________ From: 赵乾利 Sent: Saturday, April 4, 2020 14:46 To: Dave Anderson 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 Hi,Dave As you suggestion,i have made changes. Calling pfn_to_map to get page address was a wrong use,it just work in SPARSEMEM I'm looking for a interface like pfn_to_page,so i found two ways 1.pfn_to_map seems to work,and i didn't notice SPARSEMEM restriction 2.Combining pfn_to_phys and phy_to_page,but pfn_to_phys defined as a static function i wrote this feature in gcore-command before,pfn_to_map not defined as static,so i can call directly.... Now,I use the following code to implement,this should work + phys_to_page((obj >> OBJ_INDEX_BITS) << PAGESHIFT(), &page); Thanks ________________________________________ From: Dave Anderson <anderson(a)redhat.com&gt; Sent: Saturday, April 4, 2020 4:14 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 ----- The patch does compile cleanly, although I haven't tried compiling it on an s390x, but I'll do that soon. A couple issues with the patch: + if (!strncmp(name, "lzo", strlen("lzo"))) { + lzo_init(); + decompressor = (void *)lzo1x_decompress_safe; + } else {//todo,support more compressor + error(WARNING, "Only support lzo compressor\n"); + return 0; + } lzo_init() will have already been called by is_diskdump() here during session initialization if the dumpfile is a compressed kdump: #ifdef LZO if (lzo_init() == LZO_E_OK) dd->flags |= LZO_SUPPORTED; #endif So try_zram_decompress() should check if (dd->flags & LZO_SUPPORTED) has been set before calling lzo_init() again. And while I don't object to exporting swap_info_init(), I do have a problem with pfn_to_map(): +void swap_info_init(void); +ulong pfn_to_map(ulong); ... + obj >>= OBJ_TAG_BITS; + page = pfn_to_map(obj >> OBJ_INDEX_BITS); + obj_idx = (obj & OBJ_INDEX_MASK); The pfn_to_map() function is only relevant if the kernel is configured with SPARSEMEM. I don't see why the exported phys_to_page() function could not be used here? Thanks, 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!******/#

Hi,Dave The latest patch have been attached,please check Thanks. ________________________________________ From: Dave Anderson <anderson(a)redhat.com&gt; Sent: Monday, April 6, 2020 22:38 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 ----- The changes to defs.h and memory.c look good. My comments for diskdump.c are interspersed below, where many of them are redundant: +#ifdef LZO +static unsigned char *zram_object_addr(ulong pool, ulong handle, unsigned char *zram_buf) +{ + ulong obj, off, class, page, zspage; + struct zspage zspage_s; + physaddr_t paddr; + unsigned int obj_idx, class_idx, size; + ulong pages[2], sizes[2]; + + readmem(handle, KVADDR, &obj, sizeof(void *), "readmem address", RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + obj >>= OBJ_TAG_BITS; + phys_to_page(PTOB(obj >> OBJ_INDEX_BITS), &page); + obj_idx = (obj & OBJ_INDEX_MASK); + + readmem(page + OFFSET(page_private), KVADDR, &zspage, + sizeof(void *), "readmem address", RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem address",RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + + class_idx = zspage_s.class; + if (zspage_s.magic != ZSPAGE_MAGIC) + error(FATAL, "zspage magic incorrect:0x%x\n", zspage_s.magic); + + class = pool + OFFSET(zspoll_size_class); + class += (class_idx * sizeof(void *)); + readmem(class, KVADDR, &class, sizeof(void *), "readmem address",RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + readmem(class + OFFSET(size_class_size), KVADDR, + &size, sizeof(unsigned int), "readmem address", RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + off = (size * obj_idx) & (~machdep->pagemask); + if (off + size <= PAGESIZE()) { + if (!is_page_ptr(page, &paddr)) { + error(WARNING, "zspage not a page pointer:%lx\n", page); + return NULL; + } + readmem(paddr + off, PHYSADDR, zram_buf, size, "readmem zram buffer", RETURN_ON_ERROR); + goto out; + } + + pages[0] = page; + readmem(page + OFFSET(page_freelist), KVADDR, &pages[1], + sizeof(void *), "readmem address",RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + sizes[0] = PAGESIZE() - off; + sizes[1] = size - sizes[0]; + if (!is_page_ptr(pages[0], &paddr)) { + error(WARNING, "pages[0] not a page pointer\n"); Maybe display the bogus value in pages[0] in the message? + return NULL; + } + + readmem(paddr + off, PHYSADDR, zram_buf, sizes[0], "readmem zram buffer", RETURN_ON_ERROR); + if (!is_page_ptr(pages[1], &paddr)) { + error(WARNING, "pages[1] not a page pointer\n"); Maybe display the bogus value in pages[1] in the message? + return NULL; + } + + readmem(paddr, PHYSADDR, zram_buf + sizes[0], sizes[1], "readmem zram buffer", RETURN_ON_ERROR); + +out: + readmem(page, KVADDR, &obj, sizeof(void *), "readmem address",RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + if (!(obj & (1<<10))) { //PG_OwnerPriv1 flag + return (zram_buf + ZS_HANDLE_SIZE); + } + + return zram_buf; +} + +static unsigned char *lookup_swap_cache(ulong pte_val, unsigned char *zram_buf) +{ + ulong swp_type, swp_offset, swp_space; + struct list_pair lp; + physaddr_t paddr; + swp_type = __swp_type(pte_val); + if (THIS_KERNEL_VERSION >= LINUX(2,6,0)) { + swp_offset = (ulonglong)__swp_offset(pte_val); + } else { + swp_offset = (ulonglong)SWP_OFFSET(pte_val); + } + + if (!symbol_exists("swapper_spaces")) + return NULL; + swp_space = symbol_value("swapper_spaces"); + swp_space += swp_type * sizeof(void *); + + readmem(swp_space, KVADDR, &swp_space, sizeof(void *), + "readmem address",RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + swp_space += (swp_offset >> SWAP_ADDRESS_SPACE_SHIFT) * SIZE(address_space); + + lp.index = swp_offset; + if (do_radix_tree(swp_space, RADIX_TREE_SEARCH, &lp)){ + fprintf(fp, "Find page in swap cache\n"); I don't think you meant to leave this message, right? + if (!is_page_ptr((ulong)lp.value, &paddr)) { + error(WARNING, "radix page not a page pointer\n"); + return NULL; + } + readmem(paddr, PHYSADDR, zram_buf, PAGESIZE(), "readmem zram buffer", RETURN_ON_ERROR); + return zram_buf; + } + return NULL; +} + +ulong (*decompressor)(unsigned char *in_addr, ulong in_size, unsigned char *out_addr, ulong *out_size, void *other/* NOT USED */); +/* +try_zram_decompress returns decompressed page data and data length +If userspace address was swaped out to zram,call this function to decompress this object. +*/ +ulong try_zram_decompress(ulong pte_val, unsigned char *buf, ulong len, uint32_t off) +{ + char name[32] = {0}; + ulonglong swp_offset; + ulong swap_info, bdev, bd_disk, zram, zram_table_entry, sector, index, entry, flags, size, outsize; + unsigned char *obj_addr = NULL; + unsigned char *zram_buf = NULL; + unsigned char *outbuf = NULL; + + + if (!symbol_exists("swap_info")) + return 0; + + swap_info = symbol_value("swap_info"); + + swap_info_init(); + if (vt->flags & SWAPINFO_V2) { + swap_info += (__swp_type(pte_val) * sizeof(void *)); + readmem(swap_info, KVADDR, &swap_info, + sizeof(void *), "readmem address", RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + } else { + swap_info += (SIZE(swap_info_struct) * __swp_type(pte_val)); + } + + readmem(swap_info + OFFSET(swap_info_struct_bdev), KVADDR, &bdev, + sizeof(void *), "read swap_info_struct_bdev", RETURN_ON_ERROR); + readmem(bdev + OFFSET(block_device_bd_disk), KVADDR, &bd_disk, + sizeof(void *), "read block_device_bd_disk", RETURN_ON_ERROR); + readmem(bd_disk + OFFSET(gendisk_disk_name), KVADDR, name, + strlen("zram"), "read gendisk_disk_name", RETURN_ON_ERROR); + if (!strncmp(name, "zram", strlen("zram"))) { + if (CRASHDEBUG(2)) + error(WARNING, "This page has swaped to zram\n"); + + readmem(bd_disk + OFFSET(gendisk_private_data), KVADDR, &zram, + sizeof(void *), "gendisk_private_data", RETURN_ON_ERROR); + + readmem(zram + OFFSET(zram_compressor), KVADDR, name, + sizeof(name), "zram compressor", RETURN_ON_ERROR); + if (!strncmp(name, "lzo", strlen("lzo"))) { + if (!(dd->flags & LZO_SUPPORTED)) { + if (lzo_init() == LZO_E_OK) + dd->flags |= LZO_SUPPORTED; + else + return 0; + } + decompressor = (void *)lzo1x_decompress_safe; + } else {//todo,support more compressor + error(WARNING, "Only support lzo compressor\n"); + return 0; + } + + if (THIS_KERNEL_VERSION >= LINUX(2, 6, 0)) { + swp_offset = (ulonglong)__swp_offset(pte_val); + } else { + swp_offset = (ulonglong)SWP_OFFSET(pte_val); + } + + if ((zram_buf = (unsigned char*)malloc(PAGESIZE())) == NULL) + error(FATAL, "cannot malloc zram_buf space."); Never use malloc/free for temporary buffers during runtime. Either use GETBUF()/FREEBUF() or just put it on the stack. + + /*lookup page from swap cache*/ + obj_addr = lookup_swap_cache(pte_val, zram_buf); + if (obj_addr != NULL) { + memcpy(buf, obj_addr + off, len); + goto out; + } + + sector = swp_offset << (PAGESHIFT() - 9); + index = sector >> SECTORS_PER_PAGE_SHIFT; + readmem(zram, KVADDR, &zram_table_entry, + sizeof(void *), "readmem address", RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + zram_table_entry += (index * SIZE(zram_table_entry)); + readmem(zram_table_entry, KVADDR, &entry, + sizeof(void *), "readmem address", RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + readmem(zram_table_entry + OFFSET(zram_table_flag), KVADDR, &flags, + sizeof(void *), "readmem address", RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + if (!entry || (flags & ZRAM_FLAG_SAME_BIT)) { + memset(buf, entry, len); + goto out; + } + size = flags & (ZRAM_FLAG_SHIFT -1); + if (size == 0) { + len = 0; + goto out; + } + + readmem(zram + OFFSET(zram_mempoll), KVADDR, &zram, + sizeof(void *), "readmem address", RETURN_ON_ERROR); Can you make the error message type string something more helpful than "readmem address"? + + obj_addr = zram_object_addr(zram, entry, zram_buf); + if (obj_addr == NULL) { + len = 0; + goto out; + } + + if (size == PAGESIZE()) { + memcpy(buf, obj_addr + off, len); + } else { + if ((outbuf = (unsigned char*)malloc(PAGESIZE())) == NULL) + error(FATAL, "cannot malloc outbuf space."); Never use malloc/free for temporary buffers during runtime. Either use GETBUF()/FREEBUF() or just put it on the stack. + + if (!decompressor(obj_addr, size, outbuf, &outsize, NULL)) + memcpy(buf, outbuf + off, len); + else { + error(WARNING, "zram decompress error\n"); + len = 0; + } + free(outbuf); + } + } + +out: + free(zram_buf); + return len; +} +#else +ulong try_zram_decompress(ulong pte_val, unsigned char *buf, ulong len, uint32_t off) +{ + return 0; +} +#endif #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!******/#

Hi,Dave I modified RETURN_ON_ERROR to FAULT_ON_ERROR in all readmem,patch has attached. The reason for adding "decompress success" is that i want indicate that zram address is different from the normal address,and calling zram_decompress not only readmem failures,but also decompression failures etc.i add "This page has swaped to zram"/"zram decompress success" as the signature log,and these log only printed when pc->debug >= 2. When gcore read UVA address,there may be many page fault happened,we can only deal with zram swap,"not mapped" and other types of swap will not be processed.For debug request,we may need the signature log for zram. so i think it's better to keep this log. Thanks. ________________________________________ From: Dave Anderson <anderson(a)redhat.com&gt; Sent: Wednesday, April 8, 2020 0:44 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 ----- In diskdump.c, I should have noticed this before, but there a fundamental problem with *all* of your readmem() calls, because you qualify each of them with RETURN_ON_ERROR -- and then just continue on presuming that they were successful. If RETURN_ON_ERROR is specified, you need to check the return value of readmem(), and then proceed appropriately. However, as far as I can tell, all of your readmem() calls should be FAULT_ON_ERROR. That way, if the readmem() call fails, you will see the error message using your supplied "type" string, and the command will be aborted immediately. And speaking of your readmem() error message type strings, please remove the "readmem " part of the strings. For example, + readmem(page + OFFSET(page_private), KVADDR, &zspage, + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR); Just make them "page_private", "zspage", etc. And re-thinking memory.c, there really is no point in displaying the "zram decompress success" message. If try_zram_compress() fails, you will see the reason why it failed based upon the error message generated by the failing embedded/secondary readmem() call. If it works OK, you will see the requested data. Why bother to show "success"? + cnt = try_zram_decompress(paddr, (unsigned char *)bufptr, cnt, PAGEOFFSET(addr)); + if (cnt) { + if (CRASHDEBUG(2)) + error(INFO, "0x%lx zram decompress success\n", addr); + bufptr += cnt; + addr += cnt; + size -= cnt; + continue; + } Thanks, Dave + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR);+ readmem(page + OFFSET(page_private), KVADDR, &zspage, + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR); + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR);+ readmem(page + OFFSET(page_private), KVADDR, &zspage, + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR); + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR);+ readmem(page + OFFSET(page_private), KVADDR, &zspage, + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR);+ readmem(page + OFFSET(page_private), KVADDR, &zspage, + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR); + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR); + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR); + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR);+ readmem(page + OFFSET(page_private), KVADDR, &zspage, + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR); + sizeof(void *), "readmem page_private", RETURN_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "readmem zspage", RETURN_ON_ERROR); #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!******/#

I got little problem to compile 32-bit on my x86-64 host.. 96 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc 97 /usr/bin/ld: cannot find -lgcc 98 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so when searching for -lgcc_s 99 /usr/bin/ld: cannot find -lgcc_s I think i have fixed the build warning,but failed rebuild in 32-bit since above error,please help confirm,and move log to try_zram_decompress,please check the attachment. ________________________________________ From: Dave Anderson <anderson(a)redhat.com&gt; Sent: Friday, April 10, 2020 1:00 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 ----- OK fine, but please move the message out of readmem(), and put it at the end of try_zram_decompress() where it really belongs. You'll have to replace the "PAGEOFFSET(addr)" argument with "ulonglong addr", and then do the PAGEOFFSET() in try_zram_decompress(). Also, this doesn't compile cleanly on 32-bit architectures: $ make warn TARGET: X86 CRASH: 7.2.9rc10 GDB: 7.6 ... cc -c -g -DX86 -m32 -D_FILE_OFFSET_BITS=64 -DLZO -DSNAPPY -DGDB_7_6 diskdump.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security diskdump.c: In function 'lookup_swap_cache': diskdump.c:2657:2: warning: right shift count >= width of type [enabled by default] swp_type = __swp_type(pte_val); ^ diskdump.c:2659:3: warning: right shift count >= width of type [enabled by default] swp_offset = (ulonglong)__swp_offset(pte_val); ^ diskdump.c: In function 'try_zram_decompress': diskdump.c:2709:3: warning: right shift count >= width of type [enabled by default] swap_info += (__swp_type(pte_val) * sizeof(void *)); ^ diskdump.c:2713:3: warning: right shift count >= width of type [enabled by default] swap_info += (SIZE(swap_info_struct) * __swp_type(pte_val)); ^ diskdump.c:2745:4: warning: right shift count >= width of type [enabled by default] swp_offset = (ulonglong)__swp_offset(pte_val); ... Thanks, 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!******/#

Make the mistake cause by patch update.... please re-check the new patch ________________________________________ From: Dave Anderson <anderson(a)redhat.com&gt; Sent: Friday, April 10, 2020 22:57 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 ----- The patch now compiles OK, but my first simple test shows that something is obviously wrong with the patch. Here are a set of user-space addresses that have been swapped out to disk: crash> set 1 PID: 1 COMMAND: "systemd" TASK: ffff92a13a1e8000 [THREAD_INFO: ffff92a13a260000] CPU: 2 STATE: TASK_INTERRUPTIBLE crash> vm -p | grep SWAP 55d917fb5000 SWAP: /dev/dm-2 OFFSET: 55827 55d917fb7000 SWAP: /dev/dm-2 OFFSET: 55828 55d917fc2000 SWAP: /dev/dm-2 OFFSET: 121359 55d917fc6000 SWAP: /dev/dm-2 OFFSET: 88579 55d917fcb000 SWAP: /dev/dm-2 OFFSET: 88581 55d917fcc000 SWAP: /dev/dm-2 OFFSET: 88582 55d917fcd000 SWAP: /dev/dm-2 OFFSET: 88583 55d917fce000 SWAP: /dev/dm-2 OFFSET: 104963 55d917fcf000 SWAP: /dev/dm-2 OFFSET: 104964 ... Obviously any read of the addresses above should fail, but each read returns successfully, and each read is screwing up the internal buffering scheme: crash> rd -u 55d917fb5000 55d917fb5000: 0000000000000000 ........ WARNING: malloc/free mismatch (53/54) crash> rd -u 55d917fb7000 55d917fb7000: 0000000000000000 ........ WARNING: malloc/free mismatch (53/55) crash> rd -u 55d917fc2000 55d917fc2000: 0000000000000000 ........ WARNING: malloc/free mismatch (53/56) crash> rd -u 55d917fc6000 55d917fc6000: 0000000000000000 ........ WARNING: malloc/free mismatch (53/57) crash> 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!******/#

Hi, hatayama May I ask about how the patch of support the zram in gcore?support in crash is ready. Is there anything else I can do for you? ________________________________________ From: Dave Anderson <anderson(a)redhat.com&gt; Sent: Monday, April 13, 2020 20:17 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 ----- In the interest of expediency, I went ahead and made a few cosmetic changes to the comments and error message strings, and queued the patch for crash-7.2.9: https://github.com/crash-utility/crash/commit/b12bdd36cf7caad24957c0b8c03... Thanks, 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!******/#

​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 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. commit 34be98f4944f99076f049a6806fc5f5207a755d3 Author: Ard Biesheuvel <ard.biesheuvel(a)linaro.org&gt; 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&gt; [Mark: rebase, kill THREAD_START_SP, commit msg additions] Signed-off-by: Mark Rutland <mark.rutland(a)arm.com&gt; Reviewed-by: Will Deacon <will.deacon(a)arm.com&gt; Tested-by: Laura Abbott <labbott(a)redhat.com&gt; Cc: Catalin Marinas <catalin.marinas(a)arm.com&gt; Cc: James Morse <james.morse(a)arm.com&gt; ________________________________ From: d.hatayama(a)fujitsu.com <d.hatayama(a)fujitsu.com&gt; Sent: Tuesday, April 14, 2020 20:16 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 Zhao, I don't find latest patch for gcore command, but looking at the commit b12bdd36cf7caad24957c0b8c030001321ab2df4 in crash utility, try_zram_decompress() is called after uvtop() in the final design, not uvtop() being replaced by readmem(UVADDR), which can more easilly be into the gcore source code. Please send a new patch based on the latest design. It's very helpful if you share test set for this ZRAM support work. Also, for the other independent aarch64 patch, as I already requested, please tell me the kernel commit that made the corresponding change on Aaarch64 kernel statck data structure, which I need it to check whether your patch is correct or not and to file it for maintenance purpose. ________________________________ 差出人: 赵乾利 <zhaoqianli(a)xiaomi.com&gt; 送信日時: 2020年4月13日 22:41 宛先: Dave Anderson <anderson(a)redhat.com&gt; CC: Hatayama, Daisuke/畑山 大輔 <d.hatayama(a)fujitsu.com>; Discussion list for crash utility usage, maintenance and development <crash-utility(a)redhat.com&gt; 件名: Re: 答复: [External Mail]Re: [Crash-utility] zram decompress support for gcore/crash-utility Hi, hatayama May I ask about how the patch of support the zram in gcore?support in crash is ready. Is there anything else I can do for you? ________________________________________ From: Dave Anderson <anderson(a)redhat.com&gt; Sent: Monday, April 13, 2020 20:17 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 ----- In the interest of expediency, I went ahead and made a few cosmetic changes to the comments and error message strings, and queued the patch for crash-7.2.9: https://github.com/crash-utility/crash/commit/b12bdd36cf7caad24957c0b8c03... Thanks, 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!******/#

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(a)fujitsu.com <d.hatayama(a)fujitsu.com&gt; 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/b12bdd36cf7caad24957c0b8c03... 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(a)linaro.org&gt; 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&gt; [Mark: rebase, kill THREAD_START_SP, commit msg additions] Signed-off-by: Mark Rutland <mark.rutland(a)arm.com&gt; Reviewed-by: Will Deacon <will.deacon(a)arm.com&gt; Tested-by: Laura Abbott <labbott(a)redhat.com&gt; Cc: Catalin Marinas <catalin.marinas(a)arm.com&gt; Cc: James Morse <james.morse(a)arm.com&gt;? #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!******/#