crash (8.0.2-1ubuntu1) mantic; urgency=medium
* Merge with Debian; remaining changes:
- Add linux-libc-dev dependency for the autopkg test. This package
gets usually broken with kernel upgrades, so let it already show
in the autopkg test.
- Run autopkg test with allow-stderr.
crash (8.0.2-1) unstable; urgency=medium
* New upstream
* commit f1cd581d1c4afa5b8ffdfaa6a3ea9f545fe4ec91
* Author: Kazuhito Hagio <email address hidden>
* Date: Wed Nov 16 13:13:39 2022 +0900
*
* crash-8.0.1 -> crash-8.0.2
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit a158590f475c8d6d504b0c5e28b3cd91cfd47877
* Author: Lianbo Jiang <email address hidden>
* Date: Wed Nov 9 14:21:57 2022 +0800
*
* Fix for "ps/vm" commands to display correct %MEM and RSS values
*
* The ps/vm commands may print the bogus value of the %MEM and RSS, the
* reason is that the counter of rss stat is updated in asynchronous manner
* and may become negative, when the SPLIT_RSS_COUNTING is enabled in
* kernel.
*
* As a result, crash will read it from memory and convert from negative to
* unsigned long integer, eventually it overflows and gets a big integer.
* For example:
*
* crash> ps 1393
* PID PPID CPU TASK ST %MEM VSZ RSS COMM
* 1393 1 24 ffff9584bb542100 RU 541298032135.9 4132 18014398509481908 enlinuxpc64
* ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
*
* This is unexpected, crash needs to correct its value for this case.
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 21139d9456ee41ffc8cec804dc530d6934ddac89
* Author: Matias Ezequiel Vara Larsen <email address hidden>
* Date: Mon Oct 24 11:35:29 2022 +0200
*
* Fix segmentation fault in page_flags_init_from_pageflag_names()
*
* When read_string() fails in page_flags_init_from_pageflag_names(),
* error() dereferences the name variable to print the string that the
* variable points to. However, name points to a string that is not in
* crash's memory-space thus triggering a segmentation fault.
*
* This patch replaces "%s" in the error message with "%lx" so the address
* is printed instead. Also replaces "%ld" for mask with "%lx".
*
* [ kh: changed the conversion specifiers and commit message ]
*
* Signed-off-by: Matias Ezequiel Vara Larsen <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 487551488b15fcd135b29990593699a121730219
* Author: Lianbo Jiang <email address hidden>
* Date: Tue Oct 4 18:57:11 2022 +0800
*
* ppc64: still allow oneto move on if the emergency stacks info fails to
* initialize
*
* Currently crash will fail and then exit, if the initialization of
* the emergency stacks information fails. In real customer environments,
* sometimes, a vmcore may be partially damaged, although such vmcores
* are rare. For example:
*
* # ./crash ../3.10.0-1127.18.2.el7.ppc64le/vmcore
* ../3.10.0-1127.18.2.el7.ppc64le/vmlinux -s
* crash: invalid kernel virtual address: 38 type:
* "paca->emergency_sp"
* #
*
* Lets try to keep loading vmcore if such issues happen, so call
* the readmem() with the RETURN_ON_ERROR instead of FAULT_ON_ERROR,
* which allows the crash move on.
*
* Reported-by: Dave Wysochanski <email address hidden>
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 3b5e3e1583a1f596360c04e8a322e30cf88f27ab
* Author: Tao Liu <email address hidden>
* Date: Mon Sep 19 17:49:23 2022 +0800
*
* Let "kmem" print task context with physical address
*
* Patch [1] enables "kmem" to print task context if the given virtual
* address is a vmalloced stack.
*
* This patch lets "kmem" print task context also when the given address
* is a physical address.
*
* Before:
* crash> kmem 1883700e28
* VMAP_AREA VM_STRUCT ADDRESS RANGE SIZE
* ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000 20480
*
* PAGE PHYSICAL MAPPING INDEX CNT FLAGS
* ffffdd28220dc000 1883700000 0 0 1 50000000000000
*
* After:
* crash> kmem 1883700e28
* PID: 847
* COMMAND: "khungtaskd"
* TASK: ffff94f8038f4000 [THREAD_INFO: ffff94f8038f4000]
* CPU: 72
* STATE: TASK_RUNNING (PANIC)
*
* VMAP_AREA VM_STRUCT ADDRESS RANGE SIZE
* ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000 20480
*
* PAGE PHYSICAL MAPPING INDEX CNT FLAGS
* ffffdd28220dc000 1883700000 0 0 1 50000000000000
*
* [1]: https://listman.redhat.com/archives/crash-utility/2022-September/010115.html
*
* [ kh: squashed the 4/4 patch into 3/4 ]
*
* Signed-off-by: Tao Liu <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 60cb8650a0126abda661c44d198ebde514eca3e2
* Author: Tao Liu <email address hidden>
* Date: Mon Sep 19 17:49:22 2022 +0800
*
* Fix page offset issue when converting physical to virtual address
*
* When trying to convert a physical address to its virtual
* address in dump_vmap_area() and dump_vmlist(), the vi->retval
* is added by 2 values: the page aligned address "pcheck"
* and page offset address "PAGEOFFSET(paddr)".
*
* However "paddr" is given by "pcheck", is also page aligned,
* so "PAGEOFFSET(paddr)" is always 0.
*
* In this patch, we will use PAGEOFFSET(vi->spec_addr) to give the
* page offset, vi->spec_addr is the physical address we'd like
* to convert, which contains the correct page offset.
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit ad1397a73594d65aaad9d0b9a94a1dd75d8c61dd
* Author: Tao Liu <email address hidden>
* Date: Mon Sep 19 17:49:21 2022 +0800
*
* Fix "kmem" failing to print task context when address is vmalloced stack
*
* When kernel enabled CONFIG_VMAP_STACK, stack can be allocated to
* vmalloced area. Currently crash didn't handle the case, as a result,
* "kmem" will not print the task context as expected. This patch fix the
* bug by checking if the address is a vmalloced stack first.
*
* Before:
* crash> kmem ffffb7efce9bbe28
* VMAP_AREA VM_STRUCT ADDRESS RANGE SIZE
* ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000 20480
*
* PAGE PHYSICAL MAPPING INDEX CNT FLAGS
* ffffdd28220dc000 1883700000 0 0 1 50000000000000
*
* After:
* crash> kmem ffffb7efce9bbe28
* PID: 847
* COMMAND: "khungtaskd"
* TASK: ffff94f8038f4000 [THREAD_INFO: ffff94f8038f4000]
* CPU: 72
* STATE: TASK_RUNNING (PANIC)
*
* VMAP_AREA VM_STRUCT ADDRESS RANGE SIZE
* ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000 20480
*
* PAGE PHYSICAL MAPPING INDEX CNT FLAGS
* ffffdd28220dc000 1883700000 0 0 1 50000000000000
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit 4ea3a806d11f000f2eb1ddc72c2b7a543e319f64
* Author: Lianbo Jiang <email address hidden>
* Date: Fri Sep 16 14:00:01 2022 +0800
*
* Fix for the invalid linux_banner pointer issue
*
* Currently, crash may fail with the following error:
*
* # ./crash -s vmlinux vmcore
* WARNING: invalid linux_banner pointer: 65762078756e694c
* crash: vmlinux and vmcore do not match!
*
* The reason is that the type of the symbol in the data segment may be
* defined as 'D' or 'd'. The crash only handled the type 'D', but it
* didn't deal with the type 'd'. For example:
*
* # nm vmlinux | grep linux_banner
* ffffffff827cfa80 d linux_banner
*
* It has been observed that a vmlinux compiled by clang has this type.
* Let's add the type 'd' recognition to solve such issue.
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit bdbf5887d6259ea3108d4fa674f3794adad54d52
* Author: Kazuhito Hagio <email address hidden>
* Date: Thu Sep 1 13:42:28 2022 +0900
*
* Fix gcc-11 compiler warnings on gdb-10.2/gdb/symtab.c
*
* Without the patch, the following gcc-11 compiler warnings are emitted
* for gdb-10.2/gdb/symtab.c:
*
* symtab.c: In function 'void gdb_get_datatype(gnu_request*)':
* symtab.c:7131:31: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
* 7131 | register struct type *type;
* | ^~~~
* symtab.c:7132:31: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
* 7132 | register struct type *typedef_type;
* | ^~~~~~~~~~~~
* ...
*
* Usually we don't fix compiler warnings for gdb, but these are emitted
* even by "make clean ; make warn", which doesn't recompile the whole
* gdb, so it would be better to fix.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 51acac75cdb20caab30a85ebfec5906efe034477
* Author: Kazuhito Hagio <email address hidden>
* Date: Thu Sep 1 14:03:09 2022 +0900
*
* Fix gcc-12 compiler warnings on lkcd_*.c
*
* Without the patch, the following gcc-12 compiler warnings are emitted
* for lkcd_*.c:
*
* lkcd_v1.c: In function 'dump_lkcd_environment_v1':
* lkcd_v1.c:252:20: warning: the comparison will always evaluate as 'true' for the address of 'dh_panic_string' will never be NULL [-Waddress]
* 252 | dh && dh->dh_panic_string &&
* | ^~
* In file included from lkcd_v1.c:21:
* lkcd_vmdump_v1.h:108:30: note: 'dh_panic_string' declared here
* 108 | char dh_panic_string[DUMP_PANIC_LEN];
* | ^~~~~~~~~~~~~~~
* ...
*
* Reported-by: Lianbo Jiang <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 5b9d3e98cda9d99f3277aabec30d076e62cc5e71
* Author: Chunguang.Xu <email address hidden>
* Date: Thu Aug 25 12:07:20 2022 +0800
*
* Add debian/ubuntu vmlinux location to default search dirs
*
* Now crash cannot find debian/ubuntu kernel vmlinux, we need to
* explicitly specify the path to vmlinux. Try to add the debian
* vmlinux location to default search directories.
*
* Signed-off-by: Chunguang Xu <email address hidden>
*
* commit 3ed9ec5c8d09cffac9772abbf54214125ade9127
* Author: Tao Liu <email address hidden>
* Date: Wed Aug 31 11:54:15 2022 +0800
*
* x86_64: Correct the identifier when locating the call instruction
*
* The previous implementation to locate the call instruction is
* to strstr "call", then check whether the previous char is ' '
* or '\t'. The implementation is problematic. For example it
* cannot resolve the following disassembly string:
*
* "0xffffffffc0995378 <nfs41_callback_svc+344>:\tcall 0xffffffff8ecfa4c0 <schedule>\n"
*
* strstr will locate the "_call" and char check fails,
* as a result, extract_hex fails to get the calling address.
*
* NOTE: the issue is more likely to be reproduced when patch[1] applied.
* Because without patch[1], the disassembly string will be as follows,
* so the issue is no longer reproducible.
*
* "0xffffffffc0995378:\tcall 0xffffffff8ecfa4c0 <schedule>\n"
*
* Before the patch:
* crash> bt 1472
* PID: 1472 TASK: ffff8c121fa72f70 CPU: 18 COMMAND: "nfsv4.1-svc"
* #0 [ffff8c16231a3db8] __schedule at ffffffff8ecf9ef3
* #1 [ffff8c16231a3e40] schedule at ffffffff8ecfa4e9
*
* After the patch:
* crash> bt 1472
* PID: 1472 TASK: ffff8c121fa72f70 CPU: 18 COMMAND: "nfsv4.1-svc"
* #0 [ffff8c16231a3db8] __schedule at ffffffff8ecf9ef3
* #1 [ffff8c16231a3e40] schedule at ffffffff8ecfa4e9
* #2 [ffff8c16231a3e50] nfs41_callback_svc at ffffffffc099537d [nfsv4]
* #3 [ffff8c16231a3ec8] kthread at ffffffff8e6b966f
* #4 [ffff8c16231a3f50] ret_from_fork at ffffffff8ed07898
*
* This patch fix the issue by strstr "\tcall" and " call", to
* locate the correct call instruction.
*
* [1]: https://listman.redhat.com/archives/crash-utility/2022-August/010085.html
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit 2145b2bb79c59aa25c5155a8f9851554d1813fb9
* Author: Tao Liu <email address hidden>
* Date: Wed Aug 31 11:54:13 2022 +0800
*
* Let gdb get kernel module symbols info from crash
*
* Gdb will try to resolve an address to its corresponding symbol name
* such as when printing a structure. It works fine for kernel symbols,
* because gdb can find them through vmlinux. However as for kernel
* modules symbols, crash resolves them by dig into "struct module",
* which gdb don't know. As a result, gdb fails to translate a kernel
* module address to its symbol name without "mod -s|-S" options. For
* example we can reproduce the issue as follows.
*
* crash> timer
* ....
* 4331308176 336 ffff94ea24240860 ffffffffc03762c0 <estimation_timer>
* ....
* crash> sym 0xffffffffc03762c0
* ffffffffc03762c0 (t) estimation_timer [ip_vs]
*
* Before patch:
* crash> timer_list ffff94ea24240860
* struct timer_list {
* ....
* function = 0xffffffffc03762c0,
* ....
* }
*
* After patch:
* crash> timer_list ffff94ea24240860
* struct timer_list {
* ....
* function = 0xffffffffc03762c0 <estimation_timer>,
* ....
* }
*
* In this patch, we add an interface for gdb, when gdb trying to build
* kernel module's address symbolic, the info can be get from crash.
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit 9cbfea67eb4f094d47cd841b73ddbbdbe6b58696
* Author: Tao Liu <email address hidden>
* Date: Thu Aug 25 14:39:44 2022 +0800
*
* Fix "task -R" by adding end identifier for union in task_struct
*
* Previously, the start and end identifiers for union are " {\n" and
* " }, \n". However the end identifier is not always as expected.
* " },\n" can also be the end identifier with gdb-10.2. As a result,
* variable "randomized" is in incorrect state after union, and fails to
* identify the later struct members. For example, we can reproduce the
* issue as follows:
*
* crash> task
* PID: 847 TASK: ffff94f8038f4000 CPU: 72 COMMAND: "khungtaskd"
* struct task_struct {
* thread_info = {
* flags = 2148024320,
* status = 0,
* preempt_lazy_count = 0
* },
* {
* <the union>
* },
* ...
* wake_entry = {
* next = 0x0
* },
* ...
*
* Before patch:
*
* crash> task -R wake_entry
* PID: 847 TASK: ffff94f8038f4000 CPU: 72 COMMAND: "khungtaskd"
*
* After patch:
*
* crash> task -R wake_entry
* PID: 847 TASK: ffff94f8038f4000 CPU: 72 COMMAND: "khungtaskd"
* wake_entry = {
* next = 0x0
* },
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit f02c8e87fccb1a92fbc025883bc69b6467a4e6c8
* Author: Huang Shijie <email address hidden>
* Date: Mon Aug 22 09:29:32 2022 +0000
*
* arm64: use TCR_EL1_T1SZ to get the correct info if vabits_actual is
* missing
*
* After kernel commit 0d9b1ffefabe ("arm64: mm: make vabits_actual a build
* time constant if possible"), the vabits_actual is not compiled to kernel
* symbols when "VA_BITS > 48" is false.
*
* So the crash will not find the vabits_actual symbol, and it will fail
* in the end like this:
*
* # ./crash
* ...
* WARNING: VA_BITS: calculated: 46 vmcoreinfo: 48
* crash: invalid kernel virtual address: ffff88177ffff000 type: "pud page"
*
* This patch introduces the arm64_set_va_bits_by_tcr(), and if crash
* cannot find vabits_actual symbol, it will use the TCR_EL1_T1SZ
* register to get the correct VA_BITS_ACTUAL/VA_BITS/VA_START.
*
* Tested this patch with:
* 1.) the live mode with /proc/kcore
* 2.) the kdump file with /proc/vmcore.
*
* Signed-off-by: Huang Shijie <email address hidden>
*
* commit 4c85e982d25a259f81b5e8c230a67d40d4527ddf
* Author: Lianbo Jiang <email address hidden>
* Date: Wed Aug 24 10:19:20 2022 +0800
*
* gdb: fix for assigning NULL to std::string
*
* When trying to load a module with "mod -s" without its separated debug
* info file installed, the crash utility will abort as below:
*
* crash> mod -s kpatch_test kpatch_test.ko
* ...
* terminate called after throwing an instance of 'std::logic_error'
* what(): basic_string::_M_construct null not valid
* Aborted (core dumped)
*
* Let's return the std::string() instead of std::string(NULL) when a
* string is null, because the check_specified_kernel_debug_file() may
* return NULL.
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit c2743ad474529951ace2b8ec712bf373f3a07d4c
* Author: Kazuhito Hagio <email address hidden>
* Date: Mon Aug 22 11:59:46 2022 +0900
*
* Makefile: Fix unnecessary re-patching with coreutils-9.0
*
* "sum" command in coreutils-9.0 (e.g. Fedora 36) started to output a file
* name. As a result, "make" always detects a change of gdb-10.2.patch
* wrongly and re-applies it unnecessarily.
*
* Use standard input to fix it and "md5sum" to improve detection.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 763e221388219b07bd949a9ba48768856908ec6d
* Author: Lianbo Jiang <email address hidden>
* Date: Thu Jul 28 15:11:20 2022 +0800
*
* x86_64: Fix for AMD SME issue
*
* Kernel commit changes(see [1]/[2]) may cause the failure of
* crash-utility with the following error:
*
* #./crash /home/vmlinux /home/vmcore
* ...
* For help, type "help".
* Type "apropos word" to search for commands related to "word"...
*
* crash: seek error: physical address: 8000760a14000 type: "p4d page"
*
* Let's get the "NUMBER(sme_mask)" from vmcoreinfo, and try to remove
* the C-bit from the page table entries, the intention is to get the
* true physical address.
*
* Related kernel commits:
* [1] aad983913d77 ("x86/mm/encrypt: Simplify sme_populate_pgd() and sme_populate_pgd_large()")
* [2] e7d445ab26db ("x86/sme: Use #define USE_EARLY_PGTABLE_L5 in mem_encrypt_identity.c")
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit f37df7df8a50519d80f04fb48499287892021575
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jul 22 13:44:50 2022 +0900
*
* Fix gcc-11 compiler warning on kvmdump.c
*
* Without the patch, the following gcc-11 compiler warning is emitted for
* kvmdump.c:
*
* In function 'write_mapfile_registers',
* inlined from 'write_mapfile_trailer' at kvmdump.c:947:3,
* inlined from 'kvmdump_init' at kvmdump.c:145:4:
* kvmdump.c:972:13: warning: 'write' reading 8 bytes from a region of size 4 [-Wstringop-overread]
* 972 | if (write(kvm->mapfd, &kvm->cpu_devices, sizeof(uint64_t)) != sizeof(uint64_t))
* | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* In file included from kvmdump.c:19:
* kvmdump.c: In function 'kvmdump_init':
* kvmdump.h:67:18: note: source object 'cpu_devices' of size 4
* 67 | uint32_t cpu_devices;
* | ^~~~~~~~~~~
* In file included from defs.h:26,
* from kvmdump.c:18:
* /usr/include/unistd.h:378:16: note: in a call to function 'write' declared with attribute 'access (read_only, 2, 3)'
* 378 | extern ssize_t write (int __fd, const void *__buf, size_t __n) __wur
* | ^~~~~
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 7591e3c07cef4900f6b0ca797270cb7527fb4e29
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jul 22 13:44:50 2022 +0900
*
* Fix gcc-11 compiler warning on makedumpfile.c
*
* Without the patch, the following gcc-11 compiler warning is emitted for
* makedumpfile.c:
*
* In function 'flattened_format_get_osrelease',
* inlined from 'check_flattened_format' at makedumpfile.c:236:3:
* makedumpfile.c:392:9: warning: 'fclose' called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
* 392 | fclose(pipe);
* | ^~~~~~~~~~~~
* makedumpfile.c: In function 'check_flattened_format':
* makedumpfile.c:380:21: note: returned from 'popen'
* 380 | if ((pipe = popen(buf, "r")) == NULL)
* | ^~~~~~~~~~~~~~~
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit b9c0ed124e422b7e0b1526afa3a691ad0579607b
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jul 22 13:44:50 2022 +0900
*
* Fix gcc-11 compiler warning on symbols.c
*
* Without the patch, the following gcc-11 compiler warning is emitted for
* symbols.c:
*
* symbols.c: In function 'cmd_p':
* symbols.c:7412:38: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
* 7412 | *(cpuspec-1) = ':';
* | ~~~~~~~~~~~~~^~~~~
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit f374aca364b7e8809f122678aefed1010e3c94bd
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jul 22 13:44:50 2022 +0900
*
* Fix gcc-11 compiler warnings on filesys.c
*
* Without the patch, the following gcc-11 compiler warnings are emitted
* for filesys.c:
*
* filesys.c: In function 'mount_point':
* filesys.c:718:17: warning: 'pclose' called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
* 718 | pclose(mp);
* | ^~~~~~~~~~
* filesys.c:709:27: note: returned from 'fopen'
* 709 | if ((mp = fopen(mntfile, "r")) == NULL)
* | ^~~~~~~~~~~~~~~~~~~
* filesys.c:738:17: warning: 'pclose' called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
* 738 | pclose(mp);
* | ^~~~~~~~~~
* filesys.c:723:27: note: returned from 'fopen'
* 723 | if ((mp = fopen(mntfile, "r")) == NULL)
* | ^~~~~~~~~~~~~~~~~~~
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 6722ea102264b54529afc19d347a3a7473670fdd
* Author: Qianli Zhao <email address hidden>
* Date: Mon Jul 4 16:40:01 2022 +0800
*
* arm64: Fix for st->_stext_vmlinux not initialized when set VA_BITS_ACTUAL
*
* Setting st->_stext_vmlinux to UNINITIALIZED to search for "_stext"
* from the vmlinux. In the scenario where kaslr is disabled and
* without vmcoreinfo, crash will get the wrong MODULES/VMALLOC ranges
* and cause a failure in parsing a raw RAM dumpfile.
*
* Signed-off-by: Qianli Zhao <email address hidden>
*
* commit 93b880217de239268315be942c10dfce5649db8b
* Author: Hari Bathini <email address hidden>
* Date: Mon Jul 4 10:55:46 2022 +0530
*
* ppc64: use a variable for machdep->machspec
*
* machdpep->machspec is referred to multiple times. The compiler would
* likely optimize this but nonetheless, use a variable to optimize in
* coding and also improve readability. No functional change.
*
* Signed-off-by: Hari Bathini <email address hidden>
*
* commit 4dc2f1c32d1c99586e67032c9cd62c5c4334049c
* Author: Hari Bathini <email address hidden>
* Date: Mon Jul 4 10:55:45 2022 +0530
*
* ppc64: print emergency stacks info with 'mach' command
*
* Print top address of emergency stacks with 'mach' command.
*
* Signed-off-by: Hari Bathini <email address hidden>
*
* commit cdd57e8b16aba2f5714673368d6dbc7565d59841
* Author: Hari Bathini <email address hidden>
* Date: Mon Jul 4 10:55:44 2022 +0530
*
* ppc64: handle backtrace when CPU is in an emergency stack
*
* A CPU could be in an emergency stack when it is running in real mode
* or any special scenario like TM bad thing. Also, there are dedicated
* emergency stacks for machine check and system reset interrupt. Right
* now, no backtrace is provided if a CPU is in any of these stacks.
* This change ensures backtrace is processed appropriately even when
* a CPU is in any one of these emergency stacks. Also, if stack info
* cannot be found, print that message always instead of only when
* verbose logs are enabled.
*
* Related kernel commits:
* 729b0f715371 ("powerpc/book3s: Introduce exclusive emergency stack for machine check exception.")
* b1ee8a3de579 ("powerpc/64s: Dedicated system reset interrupt stack")
*
* Signed-off-by: Hari Bathini <email address hidden>
*
* commit 4d1b968abb286ea39ea080ae073b0e2b5bfe6c4e
* Author: Hari Bathini <email address hidden>
* Date: Mon Jul 4 10:55:43 2022 +0530
*
* ppc64: rename ppc64_paca_init to ppc64_paca_percpu_offset_init
*
* ppc64_paca_init() function is specifically used to initialize percpu
* data_offset for kernels older than v2.6.36. So, the name is slightly
* misleading. Rename it to ppc64_paca_percpu_offset_init to reflect its
* purpose.
*
* Signed-off-by: Hari Bathini <email address hidden>
*
* commit 3ee5956721d9a67fe8d4c6d5022aa022c5f9a11c
* Author: Hari Bathini <email address hidden>
* Date: Mon Jul 4 10:55:42 2022 +0530
*
* ppc64: dynamically allocate h/w interrupt stack
*
* Only older kernel (v2.4) used h/w interrupt stack to store frames when
* CPU received IPI. Memory used for this in 'struct machine_specific' is
* useless for later kernels. For the sake of backward compatibility keep
* h/w interrupt stack but dynamically allocate memory for it and save
* some bytes from being wasted.
*
* Signed-off-by: Hari Bathini <email address hidden>
*
* commit c67ce5bbb8e37d28f1c26b239b203a6561f574c1
* Author: Hari Bathini <email address hidden>
* Date: Mon Jul 4 10:55:41 2022 +0530
*
* ppc64: fix bt for '-S' case
*
* Passing '-S' option to 'bt' command was intended to specify the stack
* pointer manually. But get_stack_frame() handling on ppc64 is ignoring
* this option altogether. Fix it.
*
* Signed-off-by: Hari Bathini <email address hidden>
*
* commit d8869b08548362345fc34e4cf17a1eac9bddec6b
* Author: Kazuhito Hagio <email address hidden>
* Date: Wed Jun 22 08:32:59 2022 +0900
*
* Extend field length of task attributes
*
* Nowadays, some machines have many CPU cores and memory, and some
* distributions have a larger kernel.pid_max parameter, e.g. 7 digits.
* This impairs the readability of a few commands, especially "ps" and
* "ps -l|-m" options.
*
* Let's extend the field length of the task attributes, PID, CPU, VSZ,
* and RSS to improve the readability.
*
* Without the patch:
* crash> ps
* PID PPID CPU TASK ST %MEM VSZ RSS COMM
* ...
* 2802197 2699997 2 ffff916f63c40000 IN 0.0 307212 10688 timer
* 2802277 1 0 ffff9161a25bb080 IN 0.0 169040 2744 gpg-agent
* 2806711 3167854 10 ffff9167fc498000 IN 0.0 127208 6508 su
* 2806719 2806711 1 ffff91633c3a48c0 IN 0.0 29452 6416 bash
* 2988346 1 5 ffff916f7c629840 IN 2.8 9342476 1917384 qemu-kvm
*
* With the patch:
* crash> ps
* PID PPID CPU TASK ST %MEM VSZ RSS COMM
* ...
* 2802197 2699997 2 ffff916f63c40000 IN 0.0 307212 10688 timer
* 2802277 1 0 ffff9161a25bb080 IN 0.0 169040 2744 gpg-agent
* 2806711 3167854 10 ffff9167fc498000 IN 0.0 127208 6508 su
* 2806719 2806711 1 ffff91633c3a48c0 IN 0.0 29452 6416 bash
* 2988346 1 5 ffff916f7c629840 IN 2.8 9342476 1917384 qemu-kvm
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 85f39061390f095e73d9037f015cec077441eb13
* Author: Kazuhito Hagio <email address hidden>
* Date: Wed Jun 15 10:50:13 2022 +0900
*
* Fix for "dev" command on Linux 5.11 and later
*
* The following kernel commits eventually removed the bdev_map array in
* Linux v5.11 kernel:
*
* e418de3abcda ("block: switch gendisk lookup to a simple xarray")
* 22ae8ce8b892 ("block: simplify bdev/disk lookup in blkdev_get")
*
* Without the patch, the "dev" command fails to dump block device data
* with the following error:
*
* crash> dev
* ...
* dev: blkdevs or all_bdevs: symbols do not exist
*
* To get block device's gendisk, search blockdev_superblock.s_inodes
* instead of bdev_map.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit b8f2ae6b494d706b1e4855b439c4930a6a6a2f5c
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jun 10 16:00:14 2022 +0900
*
* sbitmapq: Limit kernels without sbitmap again
*
* commit 364b2e413c69 ("sbitmapq: remove struct and member validation
* in sbitmapq_init()") allowed the use of the "sbitmapq" command
* unconditionally. Without the patch, the command fails with the
* following error on kernels without sbitmap:
*
* crash> sbitmapq ffff88015796e550
*
* sbitmapq: invalid structure member offset: sbitmap_queue_sb
* FILE: sbitmap.c LINE: 385 FUNCTION: sbitmap_queue_context_load()
*
* Now the command supports Linux 4.9 and later kernels since it was
* abstracted out, so it can be limited by the non-existence of the
* sbitmap structure.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 6bc3b74c6e2b0aaebe1bc164594e53b010efef56
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jun 10 15:52:34 2022 +0900
*
* sbitmapq: Fix for kernels without struct wait_queue_head
*
* The current struct wait_queue_head was renamed by kernel commit
* 9d9d676f595b ("sched/wait: Standardize internal naming of wait-queue heads")
* at Linux 4.13. Without the patch, on earlier kernels the "sbitmapq"
* command fails with the following error:
*
* crash> sbitmapq ffff8801790b3b50
* depth = 128
* busy = 0
* bits_per_word = 32
* ...
* sbitmapq: invalid structure member offset: wait_queue_head_head
* FILE: sbitmap.c LINE: 344 FUNCTION: sbitmap_queue_show()
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit c07068266b41450ca6821ee0a1a3adf34206015f
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jun 10 15:21:53 2022 +0900
*
* Make "dev -d|-D" options parse sbitmap on Linux 4.18 and later
*
* There have been a few reports that the "dev -d|-D" options displayed
* incorrect I/O stats due to racy blk_mq_ctx.rq_* counters. To fix it,
* make the options parse sbitmap to count I/O stats on Linux 4.18 and
* later kernels, which include RHEL8 ones.
*
* To do this, adjust to the blk_mq_tags structure of Linux 5.10 through
* 5.15 kernels, which contain kernel commit 222a5ae03cdd ("blk-mq: Use
* pointers for blk_mq_tags bitmap tags") and do not contain ae0f1a732f4a
* ("blk-mq: Stop using pointers for blk_mq_tags bitmap tags").
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 12fe6c7cdd768f87ce6e903a2bbfb0c0591585c5
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jun 10 11:49:47 2022 +0900
*
* sbitmapq: Fix for sbitmap_queue without min_shallow_depth member
*
* The sbitmap_queue.min_shallow_depth member was added by kernel commit
* a327553965de ("sbitmap: fix missed wakeups caused by sbitmap_queue_get_shallow()")
* at Linux 4.18. Without the patch, on earlier kernels the "sbitmapq"
* command fails with the following error:
*
* crash> sbitmapq ffff89bb7638ee50
*
* sbitmapq: invalid structure member offset: sbitmap_queue_min_shallow_depth
* FILE: sbitmap.c LINE: 398 FUNCTION: sbitmap_queue_context_load()
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 0d3e86fee5eead93b521a0e20a0e099ede4ab72b
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jun 10 11:49:47 2022 +0900
*
* sbitmapq: Fix for sbitmap_word without cleared member
*
* The sbitmap_word.cleared member was added by kernel commit ea86ea2cdced
* ("sbitmap: ammortize cost of clearing bits") at Linux 5.0. Without the
* patch, on earlier kernels the "sbitmapq" command fails with the
* following error:
*
* crash> sbitmapq ffff8f1a3611cf10
*
* sbitmapq: invalid structure member offset: sbitmap_word_cleared
* FILE: sbitmap.c LINE: 92 FUNCTION: __sbitmap_weight()
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 9ce31a14d1083cbb2beb4a8e6eb7b88234b79a99
* Author: Kazuhito Hagio <email address hidden>
* Date: Fri Jun 10 11:49:47 2022 +0900
*
* sbitmapq: Fix for sbitmap_queue without ws_active member
*
* The sbitmap_queue.ws_active member was added by kernel commit 5d2ee7122c73
* ("sbitmap: optimize wakeup check") at Linux 5.0. Without the patch, on
* earlier kernels the "sbitmapq" command fails with the following error:
*
* crash> sbitmapq ffff8f1a3611cf10
*
* sbitmapq: invalid structure member offset: sbitmap_queue_ws_active
* FILE: sbitmap.c LINE: 393 FUNCTION: sbitmap_queue_context_load()
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit c672d7a4c290712b32c54329cbdc1e74d122e813
* Author: Lianbo Jiang <email address hidden>
* Date: Mon Jun 6 19:09:16 2022 +0800
*
* Doc: update man page for the "bpf" and "sbitmapq" commands
*
* The information of the "bpf" and "sbitmapq" commands is missing in the man
* page of the crash utility. Let's add it to the man page.
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 68ce0b9a35d77d767872dd1a729c50e4695a30a8
* Author: Lianbo Jiang <email address hidden>
* Date: Thu Jun 2 20:12:56 2022 +0800
*
* Fix for "dev -d|-D" options to support blk-mq change on Linux v5.18-rc1
*
* Kernel commit 4e5cc99e1e48 ("blk-mq: manage hctx map via xarray") removed
* the "queue_hw_ctx" member from struct request_queue at Linux v5.18-rc1,
* and replaced it with a struct xarray "hctx_table". Without the patch, the
* "dev -d|-D" options will print an error:
*
* crash> dev -d
* MAJOR GENDISK NAME REQUEST_QUEUE TOTAL READ WRITE
*
* dev: invalid structure member offset: request_queue_queue_hw_ctx
*
* With the patch:
* crash> dev -d
* MAJOR GENDISK NAME REQUEST_QUEUE TOTAL READ WRITE
* 8 ffff8e99d0a1ae00 sda ffff8e9c14c59980 10 6 4
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 7095c8fd029e3a33117e3b67de73f504686ebfe2
* Author: Lianbo Jiang <email address hidden>
* Date: Thu Jun 2 20:12:55 2022 +0800
*
* Enhance "dev -d|-D" options to support blk-mq sbitmap
*
* Since Linux 5.16-rc1, which kernel commit 9a14d6ce4135 ("block: remove
* debugfs blk_mq_ctx dispatched/merged/completed attributes") removed the
* members from struct blk_mq_ctx, crash has not displayed disk I/O statistics
* for multiqueue (blk-mq) devices.
*
* Let's parse the sbitmap in blk-mq layer to support it.
*
* Signed-off-by: Lianbo Jiang <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit dda5b2d02b8d8de1264f84b6267582aa7a1e5a57
* Author: Kazuhito Hagio <email address hidden>
* Date: Tue May 31 17:12:16 2022 +0900
*
* gdb: print details of unnamed struct and union
*
* Currently gdb's "ptype" command does not print the details of unnamed
* structure and union deeper than second level in a structure, it prints
* only "{...}" instead. And crash's "struct" and similar commands also
* inherit this behavior, so we cannot get the full information of them.
*
* To print the details of them, change the show variable when it is an
* unnamed one like crash-7.x.
*
* Without the patch:
* crash> struct -o page
* struct page {
* [0] unsigned long flags;
* union {
* struct {...};
* struct {...};
* ...
*
* With the patch:
* crash> struct -o page
* struct page {
* [0] unsigned long flags;
* union {
* struct {
* [8] struct list_head lru;
* [24] struct address_space *mapping;
* [32] unsigned long index;
* [40] unsigned long private;
* };
* struct {
* [8] dma_addr_t dma_addr;
* };
* ...
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 0f162febebc4d11a165dd40cee00f3b0ba691a52
* Author: Qi Zheng <email address hidden>
* Date: Tue May 24 20:25:54 2022 +0800
*
* bt: arm64: add support for 'bt -n idle'
*
* The '-n idle' option of bt command can help us filter the
* stack of the idle process when debugging the dumpfiles
* captured by kdump.
*
* This patch supports this feature on ARM64.
*
* Signed-off-by: Qi Zheng <email address hidden>
*
* commit 6833262bf87177d8affe4f91b2e7d2c76ecdf636
* Author: Qi Zheng <email address hidden>
* Date: Tue May 24 20:25:53 2022 +0800
*
* bt: x86_64: filter out idle task stack
*
* When we use crash to troubleshoot softlockup and other problems,
* we often use the 'bt -a' command to print the stacks of running
* processes on all CPUs. But now some servers have hundreds of CPUs
* (such as AMD machines), which causes the 'bt -a' command to output
* a lot of process stacks. And many of these stacks are the stacks
* of the idle process, which are not needed by us.
*
* Therefore, in order to reduce this part of the interference information,
* this patch adds the -n option to the bt command. When we specify
* '-n idle' (meaning no idle), the stack of the idle process will be
* filtered out, thus speeding up our troubleshooting.
*
* And the option works only for crash dumps captured by kdump.
*
* The command output is as follows:
* crash> bt -a -n idle
* [...]
* PID: 0 TASK: ffff889ff8c34380 CPU: 8 COMMAND: "swapper/8"
*
* PID: 0 TASK: ffff889ff8c32d00 CPU: 9 COMMAND: "swapper/9"
*
* PID: 0 TASK: ffff889ff8c31680 CPU: 10 COMMAND: "swapper/10"
*
* PID: 0 TASK: ffff889ff8c35a00 CPU: 11 COMMAND: "swapper/11"
*
* PID: 0 TASK: ffff889ff8c3c380 CPU: 12 COMMAND: "swapper/12"
*
* PID: 150773 TASK: ffff889fe85a1680 CPU: 13 COMMAND: "bash"
* #0 [ffffc9000d35bcd0] machine_kexec at ffffffff8105a407
* #1 [ffffc9000d35bd28] __crash_kexec at ffffffff8113033d
* #2 [ffffc9000d35bdf0] panic at ffffffff81081930
* #3 [ffffc9000d35be70] sysrq_handle_crash at ffffffff814e38d1
* #4 [ffffc9000d35be78] __handle_sysrq.cold.12 at ffffffff814e4175
* #5 [ffffc9000d35bea8] write_sysrq_trigger at ffffffff814e404b
* #6 [ffffc9000d35beb8] proc_reg_write at ffffffff81330d86
* #7 [ffffc9000d35bed0] vfs_write at ffffffff812a72d5
* #8 [ffffc9000d35bf00] ksys_write at ffffffff812a7579
* #9 [ffffc9000d35bf38] do_syscall_64 at ffffffff81004259
* RIP: 00007fa7abcdc274 RSP: 00007fffa731f678 RFLAGS: 00000246
* RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa7abcdc274
* RDX: 0000000000000002 RSI: 0000563ca51ee6d0 RDI: 0000000000000001
* RBP: 0000563ca51ee6d0 R8: 000000000000000a R9: 00007fa7abd6be80
* R10: 000000000000000a R11: 0000000000000246 R12: 00007fa7abdad760
* R13: 0000000000000002 R14: 00007fa7abda8760 R15: 0000000000000002
* ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b
* [...]
*
* Signed-off-by: Qi Zheng <email address hidden>
* Acked-by: Kazuhito Hagio <email address hidden>
* Acked-by: Lianbo Jiang <email address hidden>
*
* commit 9705669a49c341402efd8528e8fe809379dd798d
* Author: Kazuhito Hagio <email address hidden>
* Date: Mon May 23 14:48:50 2022 +0900
*
* Makefile: add missing crash_target.o to be cleaned
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 3750803f6ae5f5ad071f86ca916dbbb17b7a83a5
* Author: Lianbo Jiang <email address hidden>
* Date: Mon May 23 18:04:16 2022 +0800
*
* sbitmapq: fix invalid offset for "sbitmap_word_depth" on Linux v5.18-rc1
*
* Kernel commit 3301bc53358a ("lib/sbitmap: kill 'depth' from
* sbitmap_word") removed the depth member from struct sbitmap_word.
* Without the patch, the sbitmapq will fail:
*
* crash> sbitmapq 0xffff8e99d0dc8010
*
* sbitmapq: invalid structure member offset: sbitmap_word_depth
* FILE: sbitmap.c LINE: 84 FUNCTION: __sbitmap_weight()
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 530fe6ad7e4d7ff6254596c1219d25ed929e3867
* Author: Lianbo Jiang <email address hidden>
* Date: Mon May 23 18:04:15 2022 +0800
*
* sbitmapq: fix invalid offset for "sbitmap_queue_round_robin" on Linux
* v5.13-rc1
*
* Kernel commit efe1f3a1d583 ("scsi: sbitmap: Maintain allocation
* round_robin in sbitmap") moved the round_robin member from struct
* sbitmap_queue to struct sbitmap. Without the patch, the sbitmapq
* will fail:
*
* crash> sbitmapq 0xffff8e99d0dc8010
*
* sbitmapq: invalid structure member offset: sbitmap_queue_round_robin
* FILE: sbitmap.c LINE: 378 FUNCTION:
* sbitmap_queue_context_load()
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit a295cb40cd5d24fb5995cc78d29c5def3843d285
* Author: Lianbo Jiang <email address hidden>
* Date: Mon May 23 18:04:14 2022 +0800
*
* sbitmapq: fix invalid offset for "sbitmap_queue_alloc_hint" on Linux v5.13-rc1
*
* Kernel commit c548e62bcf6a ("scsi: sbitmap: Move allocation hint
* into sbitmap") moved the alloc_hint member from struct sbitmap_queue
* to struct sbitmap. Without the patch, the sbitmapq will fail:
*
* crash> sbitmapq 0xffff8e99d0dc8010
*
* sbitmapq: invalid structure member offset: sbitmap_queue_alloc_hint
* FILE: sbitmap.c LINE: 365 FUNCTION: sbitmap_queue_context_load()
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 364b2e413c69daf189d2bc0238e3ba9b0dcbd937
* Author: Lianbo Jiang <email address hidden>
* Date: Mon May 23 18:04:13 2022 +0800
*
* sbitmapq: remove struct and member validation in sbitmapq_init()
*
* Let's remove the struct and member validation from sbitmapq_init(), which
* will help the crash to display the actual error when the sbitmapq fails.
*
* Without the patch:
* crash> sbitmapq ffff8e99d0dc8010
* sbitmapq: command not supported or applicable on this architecture or kernel
*
* With the patch:
* crash> sbitmapq ffff8e99d0dc8010
*
* sbitmapq: invalid structure member offset: sbitmap_queue_alloc_hint
* FILE: sbitmap.c LINE: 365 FUNCTION: sbitmap_queue_context_load()
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit ae52398a13fa9a238279114ed671c7c514c154ee
* Author: Sourabh Jain <email address hidden>
* Date: Mon May 9 12:49:56 2022 +0530
*
* ppc64: update the NR_CPUS to 8192
*
* Since the kernel commit 2d8ae638bb86 ("powerpc: Make the NR_CPUS max 8192")
* the NR_CPUS on Linux kernel ranges from 1-8192. So let's match NR_CPUS with
* the max NR_CPUS count on the Linux kernel.
*
* Signed-off-by: Sourabh Jain <email address hidden>
*
* commit 0ca55e460757172879ebc06c1a18c97163711dab
* Author: Kazuhito Hagio <email address hidden>
* Date: Tue May 10 10:27:44 2022 +0900
*
* Mark start of 8.0.2 development phase with version 8.0.1++
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
crash (8.0.1-1) UNRELEASED; urgency=medium
* commit 2d193468e5fe7ee1c6be4c73083cc5ef8d922b74
* Author: Kazuhito Hagio <email address hidden>
* Date: Tue Apr 26 10:56:43 2022 +0900
*
* crash-8.0.0 -> crash-8.0.1
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit b811a045ec994ead31b0535db221d6e89596fc99
* Author: Huang Shijie <email address hidden>
* Date: Wed Mar 30 19:03:23 2022 +0000
*
* diskdump: Optimize the boot time
*
* 1.) The vmcore file maybe very big.
*
* For example, I have a vmcore file which is over 23G,
* and the panic kernel had 767.6G memory,
* its max_sect_len is 4468736.
*
* Current code costs too much time to do the following loop:
* ..............................................
* for (i = 1; i < max_sect_len + 1; i++) {
* dd->valid_pages[i] = dd->valid_pages[i - 1];
* for (j = 0; j < BITMAP_SECT_LEN; j++, pfn++)
* if (page_is_dumpable(pfn))
* dd->valid_pages[i]++;
* ..............................................
*
* For my case, it costs about 56 seconds to finish the
* big loop.
*
* This patch moves the hweightXX macros to defs.h,
* and uses hweight64 to optimize the loop.
*
* For my vmcore, the loop only costs about one second now.
*
* 2.) Tests result:
* # cat ./commands.txt
* quit
*
* Before:
*
* #echo 3 > /proc/sys/vm/drop_caches;
* #time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
* ............................
* real 1m54.259s
* user 1m12.494s
* sys 0m3.857s
* ............................
*
* After this patch:
*
* #echo 3 > /proc/sys/vm/drop_caches;
* #time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
* ............................
* real 0m55.217s
* user 0m15.114s
* sys 0m3.560s
* ............................
*
* Signed-off-by: Huang Shijie <email address hidden>
*
* commit a3344239743bdf1c72aae0fd05903e2654dee268
* Author: Huang Shijie <email address hidden>
* Date: Mon Apr 4 17:47:53 2022 +0000
*
* diskdump: use mmap/madvise to improve the start-up
*
* Sometimes, the size of bitmap in vmcore can be very large, such as over
* 256M. This patch uses mmap/madvise to improve the performance of reading
* bitmap in the non-FLAT_FORMAT code path.
*
* Without the patch:
* #echo 3 > /proc/sys/vm/drop_caches;
* #time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
* ............................
* real 0m55.217s
* user 0m15.114s
* sys 0m3.560s
* ............................
*
* With the patch:
* #echo 3 > /proc/sys/vm/drop_caches;
* #time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
* ............................
* real 0m44.097s
* user 0m19.031s
* sys 0m1.620s
* ............................
*
* Note:
* Test files:
* vmlinux: 272M
* vmcore : 23G (bitmap_len: 4575985664)
* #cat ./commands.txt
* quit
*
* Signed-off-by: Huang Shijie <email address hidden>
*
* commit 87369080a480202c430ca823f83aa89c217fdc8f
* Author: Rongwei Wang <email address hidden>
* Date: Wed Apr 6 22:38:40 2022 +0800
*
* arm64: handle 1GB block for VM_L4_4K
*
* When arm64 is configured with PAGE_SIZE=4k and 4 level
* translation, the pagetable of all pages may be created with
* block mapping or contiguous mapping as much as possible, likes
* disable CONFIG_RODATA_FULL_DEFAULT_ENABLED. But now, vtop
* command can not handle 1GB block (PUD mapping) well, and just
* shows a seek error:
*
* crash> vtop ffff00184a800000
* VIRTUAL PHYSICAL
* ffff00184a800000 188a800000
*
* PAGE DIRECTORY: ffff8000110aa000
* PGD: ffff8000110aa000 => 203fff9003
* PUD: ffff001fffff9308 => 68001880000705
* PMD: ffff0018400002a0 => ffff8000103b4fd0
* vtop: seek error: kernel virtual address: ffff7fffd03b4000 type: "page table"
*
* This patch fixes it, and shows as following:
*
* crash> vtop ffff00184a800000
* VIRTUAL PHYSICAL
* ffff00184a800000 188a800000
*
* PAGE DIRECTORY: ffff8000110aa000
* PGD: ffff8000110aa000 => 203fff9003
* PUD: ffff001fffff9308 => 68001880000705
* PAGE: 1880000000 (1GB)
*
* PTE PHYSICAL FLAGS
* 68001880000705 1880000000 (VALID|SHARED|AF|PXN|UXN)
*
* PAGE PHYSICAL MAPPING INDEX CNT FLAGS
* fffffe00610a0000 188a800000 0 0 0 77fffe0000000000
*
* Acked-by: Kazuhito Hagio <email address hidden>
* Signed-off-by: Rongwei Wang <email address hidden>
*
* commit b89f9ccf511a6e3db17f44a815e415664937d7e6
* Author: xiaer1921 <email address hidden>
* Date: Thu Apr 7 15:05:17 2022 +0800
*
* Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB
*
* Since the following kernel commits split slab info from struct page
* into struct slab, crash cannot get several slab related offsets from
* struct page.
*
* d122019bf061 ("mm: Split slab into its own type")
* 401fb12c68c2 ("mm: Differentiate struct slab fields by sl*b implementations")
* 07f910f9b729 ("mm: Remove slab from struct page")
*
* Without the patch, "kmem -s|-S" options cannot work correctly on kernels
* configured with CONFIG_SLAB with the following error:
*
* crash> kmem -s
* kmem: invalid structure member offset: page_active
* FILE: memory.c LINE: 12225 FUNCTION: verify_slab_overload_page()
*
* Resolves: https://github.com/crash-utility/crash/issues/115
* Signed-off-by: xiaer1921 <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 8d49ad66625081dfdaf82374b5201c3a0da30e70
* Author: Lianbo Jiang <email address hidden>
* Date: Mon Mar 28 18:54:29 2022 +0800
*
* Fix the failure of resolving ".rodata" on s390x
*
* The commit <cd8954023bd4> broke crash-utility on s390x and got the
* following error:
*
* crash: cannot resolve ".rodata"
*
* The reason is that all symbols containing a "." may be filtered out
* on s390x. To prevent the current failure, do not filter out the
* symbol ".rodata" on s390x.
*
* In addition, a simple way is to check whether the symbol ".rodata"
* exists before calculating the value of a symbol, just to be on the
* safe side.
*
* Fixes: cd8954023bd4 ("kernel: fix start-up time degradation caused by
* strings command")
* Reported-by: Alexander Egorenkov <email address hidden>
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit cd8954023bd474521a9d45e2b09a7bce4174f52f
* Author: HATAYAMA Daisuke <email address hidden>
* Date: Wed Mar 23 08:09:49 2022 +0000
*
* kernel: fix start-up time degradation caused by strings command
*
* verify_namelist() uses strings command and scans full part of vmlinux
* file to find linux_banner string. However, vmlinux file is quite large
* these days, reaching over 500MB. As a result, this degradates start-up
* time of crash command 10 or more seconds. (Of course, this depends on
* machines you use for investigation, but I guess typically we cannot
* use such powerful machines to investigate crash dump...)
*
* To resolve this issue, let's use bfd library and read linux_banner
* string in vmlinux file directly.
*
* A simple benchmark shows the following result:
*
* Without the fix:
*
* # cat ./commands.txt
* quit
* # time ./crash -i ./commands.txt \
* /usr/lib/debug/lib/modules/5.16.15-201.fc35.x86_64/vmlinux \
* /var/crash/*/vmcore >/dev/null 2>&1
*
* real 0m20.251s
* user 0m19.022s
* sys 0m1.054s
*
* With the fix:
*
* # time ./crash -i ./commands.txt \
* /usr/lib/debug/lib/modules/5.16.15-201.fc35.x86_64/vmlinux \
* /var/crash/*/vmcore >/dev/null 2>&1
*
* real 0m6.528s
* user 0m6.143s
* sys 0m0.431s
*
* Note that this commit keeps the original logic that uses strings
* command for backward compatibility for in case.
*
* Signed-off-by: HATAYAMA Daisuke <email address hidden>
*
* commit 8827424f2b05587b8aaaeb7aae0ce8bcc017999f
* Author: Huang Shijie <email address hidden>
* Date: Wed Mar 23 18:25:48 2022 +0000
*
* arm64: fix the seek error of "pud page" for live debugging
*
* Crash reported an error on kernel v5.7 when live debugging with the
* command "crash vmlinux /proc/kcore":
*
* "crash: seek error: kernel virtual address: ffff75e9fffff000 type: "pud page""
*
* The reason is that the PTOV() and arm64_vtop_4level_4k() do not work
* as expected due to incorrect physvirt_offset.
*
* To fix the above issue, need to read out the virtual address of
* "physvirt_offset" from the "/proc/kallsyms", and update the
* ms->phys_offset which is initialized with a wrong value in kernel
* version [5.4, 5.10).
*
* Signed-off-by: Huang Shijie <email address hidden>
*
* commit 49df472da92be8056200c28f5b7ce82eeb7ab103
* Author: Huang Shijie <email address hidden>
* Date: Sat Mar 19 08:44:08 2022 +0000
*
* arm64: fix the wrong vmemmap_end
*
* The VMEMMAP_END did not exist before the kernel v5.7, but for now, the
* value of vmemmap_end may be set to -1(0xffffffffffffffffUL).
*
* According to the arch/arm64/mm/dump.c (before kernel v5.7):
* ..................................................
* { VMEMMAP_START + VMEMMAP_SIZE, "vmemmap end" }
* ..................................................
*
* The vmemmap_end should always be:
* vmemmap_end = vmemmap_vaddr + vmemmap_size;
*
* This patch fixes the above issue.
*
* Fixes: e397e1bef22a ("arm64: update the modules/vmalloc/vmemmap ranges")
* Signed-off-by: Huang Shijie <email address hidden>
*
* commit 01689f3ee22b7006e68afd0a45437846a45f79b1
* Author: Huang Shijie <email address hidden>
* Date: Mon Mar 14 15:13:38 2022 +0000
*
* arm64: use the vmcore info to get module/vmalloc/vmemmap ranges
*
* Since the kernel commit <2369f171d5c5> ("arm64: crash_core: Export
* MODULES, VMALLOC, and VMEMMAP ranges"), crash can obtain the range
* of module/vmalloc/vmemmap from the vmcore info, and no need to
* calculate them manually.
*
* This patch adds a new hook arm64_get_range_v5_18 which could parse
* out all the module/vmalloc/vmemmap ranges from the vmcore info.
*
* Signed-off-by: Huang Shijie <email address hidden>
*
* commit e397e1bef22afb2ed6108cf9405cefa40975f6ef
* Author: Huang Shijie <email address hidden>
* Date: Fri Mar 11 13:00:59 2022 +0000
*
* arm64: update the modules/vmalloc/vmemmap ranges
*
* Currently, the crash is implemented for arm64 based on kernel v4.20(and
* earlier), and so far the kernel has evolved to v5.17-rc4. But the ranges
* of MODULE/VMALLOC/VMEMMAP have not been updated since kernel v4.20.
*
* Without the patch:
* crash> help -m
* ...
* vmalloc_start_addr: ffff800048000000
* vmalloc_end: fffffdffbffeffff
* modules_vaddr: ffff800040000000
* modules_end: ffff800047ffffff
* vmemmap_vaddr: fffffdffffe00000
* vmemmap_end: ffffffffffffffff
* ...
*
* With the patch:
* crash> help -m
* ...
* vmalloc_start_addr: ffff800010000000
* vmalloc_end: fffffdffbffeffff
* modules_vaddr: ffff800008000000
* modules_end: ffff80000fffffff
* vmemmap_vaddr: fffffdffffe00000
* vmemmap_end: ffffffffffffffff
* ...
*
* Link: https://listman.redhat.com/archives/crash-utility/2022-March/009625.html
* Signed-off-by: Huang Shijie <email address hidden>
*
* commit 4cf262e2374bcc181dc696180e33c61962f29f24
* Author: Sergey Samoylenko <email address hidden>
* Date: Tue Mar 8 23:27:10 2022 +0300
*
* sbitmap.c: use readmem more carefully
*
* Signed-off-by: Sergey Samoylenko <email address hidden>
*
* commit 7c7a4eddb4d7570dd70467b43ef3eef469ab048f
* Author: Sergey Samoylenko <email address hidden>
* Date: Tue Mar 8 23:27:09 2022 +0300
*
* Fix memory leak in __sbitmap_for_each_set function
*
* Signed-off-by: Sergey Samoylenko <email address hidden>
*
* commit a92ff262d43d3be046db90a482d8d835278c8a8f
* Author: Kazuhito Hagio <email address hidden>
* Date: Tue Mar 1 17:18:24 2022 +0900
*
* help.c: Fix a missing new line in "sbitmapq" help page
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit e3bdc32aab5d8fe09b679cf394da8ba8826e207f
* Author: Pingfan Liu <email address hidden>
* Date: Thu Feb 24 11:52:12 2022 +0800
*
* arm64: deduce the start address of kernel code, based on kernel version
*
* After kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from
* permanent kernel mapping"), the range [_text, _stext] is reclaimed. But
* the current crash code still assumes kernel starting from "_text".
*
* This change only affects the vmalloced area on arm64 and may result a
* false in arm64_IS_VMALLOC_ADDR().
*
* Since vmcore has no extra information about this trival change, it can
* only be deduced from kernel version, which means ms->kimage_text can not
* be correctly initialized until kernel_init() finishes. Here on arm64, it
* can be done at the point machdep_init(POST_GDB). This is fine
* since there is no access to vmalloced area at this stage.
*
* Signed-off-by: Pingfan Liu <email address hidden>
*
* commit 8f19ddea508632e1241120b1807ad6f41f114e0d
* Author: Huang Shijie <email address hidden>
* Date: Thu Feb 24 10:23:56 2022 +0000
*
* Makefile: Change the behavior of target "cscope"
*
* Make the "make cscope" only generate cscope index, not call the cscope.
*
* Also fix a typo:
* cscope_out --> cscope.out
*
* Acked-by: Kazuhito Hagio <email address hidden>
* Signed-off-by: Huang Shijie <email address hidden>
*
* commit c1f45f89dcc2f0e5d0d2128f646807125794f833
* Author: Lianbo Jiang <email address hidden>
* Date: Wed Feb 23 16:00:12 2022 +0800
*
* Fix sys command to display its help information correctly
*
* Sometimes, the sys command may be misused, but it doesn't display
* the expected help information, for example:
*
* Without the patch:
* crash> sys kmem
* NAME
* kmem - kernel memory
* SYNOPSIS
* kmem [-f|-F|-c|-C|-i|-v|-V|-n|-z|-o|-h] [-p | -m member[,member]]
* [[-s|-S|-S=cpu[s]|-r] [slab] [-I slab[,slab]]] [-g [flags]] [[-P] address]]
* ...
* crash> sys abc
* crash>
*
* With the patch:
* crash> sys kmem
* Usage:
* sys [-c [name|number]] [-t] [-i] config
* Enter "help sys" for details.
* crash> sys abc
* Usage:
* sys [-c [name|number]] [-t] [-i] config
* Enter "help sys" for details.
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 0260367da785667818d84d6cbf3aefe86a518dbb
* Author: Tao Liu <email address hidden>
* Date: Tue Feb 22 10:32:15 2022 +0800
*
* Makefile: crash multi-target and multithread compile support
*
* This patch will support making crash as follows:
* $ make -j8 warn lzo
*
* Without this patch, the "make -j jobs warn lzo" will output the
* following error during crash build:
* ...
* mv: cannot stat 'Makefile.new': No such file or directory
* Makefile: cannot create new Makefile
* please copy Makefile.new to Makefile
* make: *** [Makefile:321: lzo] Error 1
* make: *** Waiting for unfinished jobs....
* TARGET: X86_64
* CRASH: 8.0.0++
* GDB: 10.2
* ...
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit b1fb3cdd87fc23f23d6811fdeb9915523e530b33
* Author: Tao Liu <email address hidden>
* Date: Wed Feb 16 17:51:53 2022 +0800
*
* x86_64_init: Refresh vmalloc region addresses in POST_RELOC instead of POST_GDB phase
*
* Previously for x86_64, when memory is randomized, the region addresses
* such as vmalloc_start_addr/vmemmap_vaddr/modules_vaddr are firstly set
* to a default value before POST_RELOC phase, then get refreshed with the
* actual value in POST_GDB phase.
*
* However for crash mininal mode, POST_GDB phase is not called, which
* leaving the region addresses unrefreshed and incorrect. As a consequence,
* the x86_64_IS_VMALLOC_ADDR check will give a faulty result when
* value_search tries to search a symbol by address.
*
* For example, in crash minimal mode we can observe the following issue:
*
* crash> dis -f panic
* dis: cannot resolve address: ffffffffb20e0d30
*
* crash> sym panic
* ffffffffb20e0d30 (T) panic /usr/src/debug/kernel-4.18.0-290/linux-4.18.0-290/kernel/panic.c: 168
* crash> sym ffffffffb20e0d30
* symbol not found: ffffffffb20e0d30
*
* In this patch, we will move the code which update the region addresses into
* POST_RELOC phase, so in mininal mode the regions can get the correct
* addresses.
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit fb64fdd11d15d2049a3facaddaaf32ff3b29e41c
* Author: Sergey Samoylenko <email address hidden>
* Date: Mon Feb 14 12:18:49 2022 +0300
*
* sbitmapq: add '-p' option
*
* The -p option says, an associated with sbitmap_queue array contains
* the pointers on a structure. This allows the sbitmapq command works
* correctly with the array of pointers attached to the sbitmap_queue.
*
* Signed-off-by: Sergey Samoylenko <email address hidden>
*
* commit ac86cc3558f8128dc0a32aad9d26db66cfc949b8
* Author: Sergey Samoylenko <email address hidden>
* Date: Mon Feb 14 12:18:48 2022 +0300
*
* Introduce sbitmapq command
*
* Patch adds new 'sbitmapq' command. This command dumps
* the contents of the sbitmap_queue structure and the used
* bits in the bitmap. Also, it shows the dump of a structure
* array associated with the sbitmap_queue.
*
* Signed-off-by: Sergey Samoylenko <email address hidden>
*
* commit 6ecb8a23ca294de5ef92726c782f4c92fcb39d92
* Author: Huang Shijie <email address hidden>
* Date: Fri Feb 11 09:46:42 2022 +0000
*
* arm64: Use CONFIG_ARM64_VA_BITS to initialize VA_BITS_ACTUAL
*
* We can get VA_BITS_ACTUAL from CONFIG_ARM64_VA_BITS by guess.
*
* Without this patch, we may need to use "--machdep vabits_actual=48" to
* set the VA_BITS_ACTUAL.
*
* Signed-off-by: Huang Shijie <email address hidden>
*
* commit 3ed30b51284b6ef6b116262d19a3dca205563061
* Author: Shogo Matsumoto <email address hidden>
* Date: Fri Jan 28 04:22:07 2022 +0000
*
* log: support "log -t|-m" option for output of printk safe buffers
*
* Suppress the output of safe buffer name with the "log -t" option and
* display the message log level with "log -m" option.
*
* Signed-off-by: Shogo Matsumoto <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit b0d447d78b5a24d248359f6285e275ef776f0a34
* Author: Shogo Matsumoto <email address hidden>
* Date: Fri Jan 28 04:17:41 2022 +0000
*
* log: introduce "log -s" option to display printk safe buffers
*
* Introduce a new "log -s" option, which outputs unflushed logs in the
* printk safe buffers (safe_print_seq and nmi_print_seq) as follows:
*
* crash> log -s
* PRINTK_SAFE_SEQ_BUF: nmi_print_seq
* CPU: 0 ADDR: ffff8ca4fbc19ce0 LEN: 150 MESSAGE_LOST: 0
* Uhhuh. NMI received for unknown reason 20 on CPU 0.
* Do you have a strange power saving mode enabled?
* Dazed and confused, but trying to continue
* ...
*
* The buffers are displayed for each CPU. For an empty buffer,
* '(empty)' will be printed.
*
* Also append those to the bottom of "log" command output so as not to
* overlook them like this:
*
* crash> log
* ...
* [nmi_print_seq] Uhhuh. NMI received for unknown reason 30 on CPU 0.",
* [nmi_print_seq] Do you have a strange power saving mode enabled?",
* [nmi_print_seq] Dazed and confused, but trying to continue",
*
* Note that the safe buffer (struct printk_safe_seq_buf) was introduced
* at kernel-4.11 (Merge commit 7d91de74436a69c2b78a7a72f1e7f97f8b4396fa)
* and removed at kernel-5.15 (93d102f094be9beab28e5afb656c188b16a3793b).
*
* Link: https://listman.redhat.com/archives/crash-utility/2022-January/msg00052.html
* Signed-off-by: Shogo Matsumoto <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit def34f57e81a2efa865de5eb218818ebff142614
* Author: Kazuhito Hagio <email address hidden>
* Date: Wed Feb 16 11:33:15 2022 +0900
*
* Makefile: Fix build failure with "make -j jobs" option
*
* The "make -j jobs" option sometimes fails with an error like this:
*
* $ make clean ; make -j $(nproc) warn
* ...
* ar: creating crashlib.a
* CXXLD gdb
* /usr/bin/ld: ../../crashlib.a(main.o): in function `dump_build_data':
* /home/crash/main.c:1829: undefined reference to `build_command'
* /usr/bin/ld: /home/crash/main.c:1830: undefined reference to `build_data'
* collect2: error: ld returned 1 exit status
* make[4]: *** [Makefile:1872: gdb] Error 1
* make[3]: *** [Makefile:10072: all-gdb] Error 2
* make[2]: *** [Makefile:860: all] Error 2
* crash build failed
*
* This is because build_data.c is compiled by two jobs and they write to
* build_data.o simultaneously and break it. Remove one of them.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 74ac929712416705a758f14a3506991bbfdc869c
* Author: Sven Schnelle <email address hidden>
* Date: Mon Dec 20 14:16:50 2021 +0100
*
* Support for multiple jobs to build crash
*
* This patch saves compilation time for crash build, which did the
* following things:
*
* [1] add --no-print-directory to MAKEFLAGS right in the beginning
* to avoid repeating it in all make calls.
* [2] use "make -C" instead of "cd x; make"
* [3] replace make by $(MAKE)
*
* Link: https://listman.redhat.com/archives/crash-utility/2021-December/msg00049.html
* Link: https://listman.redhat.com/archives/crash-utility/2021-December/msg00048.html
* Link: https://listman.redhat.com/archives/crash-utility/2021-December/msg00047.html
* Signed-off-by: Sven Schnelle <email address hidden>
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 0a4434f4cb0760d77900af9603e847da4e7afd0f
* Author: Lianbo Jiang <email address hidden>
* Date: Mon Feb 14 17:07:38 2022 +0800
*
* Doc: update man page for the option "--src directory"
*
* The "--src directory" option information is missing from the man page of
* crash utility. Originally it was added by commit 9254c7f206d5 ("Added a
* new "--src <directory>"...), let's sync this option information to the
* man page.
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 1ecb3513093ef4e40fdd27da479bc8ef844df3eb
* Author: Lianbo Jiang <email address hidden>
* Date: Mon Feb 14 16:59:10 2022 +0800
*
* Fix for "bpf -m|-M" options to appropriately display MEMLOCK and UID
*
* Kernel commit 80ee81e0403c ("bpf: Eliminate rlimit-based memory
* accounting infra for bpf maps") removed the struct bpf_map_memory
* member from struct bpf_map at Linux 5.11. Without the patch, the
* "bpf -m|-M" options will print "(unknown)" for MEMLOCK and UID:
*
* crash> bpf -m 1
* ID BPF_MAP BPF_MAP_TYPE MAP_FLAGS
* 1 ffff96ba41804400 ARRAY 00000000
* KEY_SIZE: 4 VALUE_SIZE: 8 MAX_ENTRIES: 64 MEMLOCK: (unknown)
* NAME: "dist" UID: (unknown)
*
* Signed-off-by: Lianbo Jiang <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 5f390ed811b00753ce7d5ceec5717280df16fd28
* Author: Kazuhito Hagio <email address hidden>
* Date: Wed Feb 2 02:14:56 2022 +0000
*
* Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
*
* Since the following kernel commits split slab info from struct page
* into struct slab, crash cannot get several slab related offsets from
* struct page.
*
* d122019bf061 ("mm: Split slab into its own type")
* 07f910f9b729 ("mm: Remove slab from struct page")
*
* Without the patch, "kmem -s|-S" and "bt -F[F]" options cannot work
* correctly with the following errors:
*
* crash> kmem -s kmem_cache
* CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
* kmem: page_to_nid: invalid page: ffff9454afc35020
* kmem: kmem_cache: cannot gather relevant slab data
* ffff945140042000 216 ? ? ? 8k kmem_cache
*
* crash> bt -F
* ...
* bt: invalid structure member offset: page_slab
* FILE: memory.c LINE: 9477 FUNCTION: vaddr_to_kmem_cache()
*
* Signed-by: Kazuhito Hagio <email address hidden>
*
* commit dd35cf6fc5463ff31206fbb27238b4c3802c063d
* Author: Kazuhito Hagio <email address hidden>
* Date: Wed Jan 26 06:07:00 2022 +0000
*
* arm64: Fix segfault by "bt" command with offline cpus
*
* Currently on arm64, NT_PRSTATUS notes in dumpfile are not mapped to
* online cpus and machine_specific->panic_task_regs correctly. As a
* result, the "bt" command can cause a segmentation fault.
*
* crash> bt -c 0
* PID: 0 TASK: ffff8000117fa240 CPU: 0 COMMAND: "swapper/0"
* Segmentation fault (core dumped)
*
* To fix this,
* 1) make map_cpus_to_prstatus_kdump_cmprs() map the notes to
* dd->nt_prstatus_percpu also on arm64, and
* 2) move arm64_get_crash_notes() to machdep_init(POST_INIT) in order
* to apply the mapping to machine_specific->panic_task_regs.
*
* Resolves: https://github.com/crash-utility/crash/issues/105
* Reported-by: xuchunmei000 <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
* Tested-by: David Wysochanski <email address hidden>
*
* commit e389667cf62ef5db82f9796cdbc0134ec38612dc
* Author: Tao Liu <email address hidden>
* Date: Fri Jan 21 13:43:09 2022 +0800
*
* Improve the ps performance for vmcores with large number of threads
*
* Previously, the ps command will iterate over all threads which
* have the same tgid, to accumulate their rss value, in order to
* get a thread/process's final rss value as part of the final output.
*
* For non-live systems, the rss accumulation values are identical for
* threads which have the same tgid, so there is no need to do the
* iteration and accumulation repeatly, thus a lot of readmem calls are
* skipped. Otherwise it will be the performance bottleneck if the
* vmcores have a large number of threads.
*
* In this patch, the rss accumulation value will be stored in a cache,
* next time a thread with the same tgid will take it directly without
* the iteration.
*
* For example, we can monitor the performance issue when a vmcore has
* ~65k processes, most of which are threads for several specific
* processes. Without the patch, it will take ~7h for ps command
* to finish. With the patch, ps command will finish in 1min.
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit ce92e458506aec5bc5516a771e26b0f907ce0db4
* Author: Lianbo Jiang <email address hidden>
* Date: Wed Jan 26 20:32:35 2022 +0800
*
* GDB: fix completion related libstdc++ assert
*
* Currently crash built with some specific flags (-D_GLIBCXX_ASSERTIONS
* and etc.) may abort and print the following error when running the gdb
* list command or tab-completion of symbols. For example:
*
* crash> l panic
* /usr/include/c++/11/string_view:234: ...
* Aborted (core dumped)
*
* crash> p "TAB completion"
* crash> p /usr/include/c++/11/string_view:234: ...
* Aborted (core dumped)
*
* When the name string is null (the length of name is zero), there are
* multiple places where array access is out of bounds in the gdb/ada-lang.c
* (see ada_fold_name() and ada_lookup_name_info()).
*
* The patch backports these gdb patches:
* 6a780b676637 ("Fix completion related libstdc++ assert when using -D_GLIBCXX_DEBUG")
* 2ccee230f830 ("Fix off-by-one error in ada_fold_name")
*
* Signed-off-by: Lianbo Jiang <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 2ebd8c5ecf1f077975b82325a38dd777b594d0a9
* Author: Kazuhito Hagio <email address hidden>
* Date: Wed Jan 19 16:24:49 2022 +0900
*
* Remove ptype command from "ps -t" option to reduce memory and time
*
* With some vmlinux e.g. RHEL9 ones, the first execution of the gdb ptype
* command heavily consumes memory and time. The "ps -t" option uses it in
* start_time_timespec(), and it can be replaced with the crash macros.
*
* This can reduce about 1.4 GB memory and 6 seconds time comsumption in
* the following test:
*
* $ echo "ps -t" | time crash vmlinux vmcore
*
* Without the patch:
* 11.60user 0.43system 0:11.94elapsed 100%CPU (0avgtext+0avgdata 1837964maxresident)k
* 0inputs+400outputs (0major+413636minor)pagefaults 0swaps
*
* With the patch:
* 5.40user 0.16system 0:05.46elapsed 101%CPU (0avgtext+0avgdata 417896maxresident)k
* 0inputs+384outputs (0major+41528minor)pagefaults 0swaps
*
* Although the ptype command and similar ones cannot be fully removed,
* but removing some of them will make the use of crash safer, especially
* for an automatic crash reporter.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit d16dc6fff0260ec26002046fae4aeb546d6b9a0e
* Author: Lianbo Jiang <email address hidden>
* Date: Mon Jan 17 15:14:00 2022 +0800
*
* Move the initialization of "boot_date" to task_init()
*
* The "boot_date" is initialized conditionally in the cmd_log(), which may
* display incorrect "boot_date" value with the following command before
* running the "log -T" command:
*
* crash> help -k | grep date
* date: Wed Dec 22 13:39:29 IST 2021
* boot_date: Thu Jan 1 05:30:00 IST 1970
* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* The calculation of "boot_date" depends on the HZ value, and the HZ will
* be calculated in task_init() at the latest, so let's move it here.
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 14f8c460473c8613553b5defd174ca2af812ddcb
* Author: Alexander Egorenkov <email address hidden>
* Date: Mon Dec 6 16:04:19 2021 +0100
*
* memory: Handle struct slab changes on Linux 5.17-rc1 and later
*
* Since kernel commit d122019bf061 ("mm: Split slab into its own type"),
* the struct slab is used for both SLAB and SLUB. Therefore, don't depend
* on the non-presence of the struct slab to decide whether SLAB implementation
* should be chosen and use the member variable "cpu_slab" of the struct
* kmem_cache instead, it should be present only in SLUB.
*
* Without the patch, crash fails to start with the error message:
*
* crash: invalid structure member offset: kmem_cache_s_num
* FILE: memory.c LINE: 9619 FUNCTION: kmem_cache_init()
*
* Signed-off-by: Alexander Egorenkov <email address hidden>
*
* commit b9dc76e232e0226a14ae3089e3be5c915f2bb981
* Author: Lianbo Jiang <email address hidden>
* Date: Mon Jan 10 17:25:06 2022 +0800
*
* Fix for HZ calculation on Linux 5.14 and later
*
* Kernel commit 3e9a99eba058 ("block/mq-deadline: Rename dd_init_queue()
* and dd_exit_queue()") renamed dd_init_queue to dd_init_sched. Without
* the patch, the 'help -m' may print incorrect hz value as follows:
*
* crash> help -m | grep hz
* hz: 1000 <---The correct hz value on ppc64le machine is 100.
* ^^^^
*
* Fixes: b93027ce5c75 ("Add alternate HZ calculation using write_expire")
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 0d3d80b47d69c5d303b48c0463a026e60633cae2
* Author: Lianbo Jiang <email address hidden>
* Date: Thu Jan 6 12:01:17 2022 +0800
*
* Fix for "bt -v" option to display the stack-end address correctly
*
* The "bt -v" command prints incorrect stack-end address when the
* "CONFIG_THREAD_INFO_IN_TASK=y" is enabled in kernel, the "bt -v"
* command output shows that the value stored at 0xffff8dee0312c198
* is 0xffffffffc076400a, however, the value stored actually at
* 0xffff8dee0312c198 is NULL(0x0000000000000000), the stack-end
* address is incorrect.
*
* Without the patch:
* crash> bt -v
* PID: 28642 TASK: ffff8dee0312c180 CPU: 0 COMMAND: "insmod"
* possible stack overflow: ffff8dee0312c198: ffffffffc076400a != STACK_END_MAGIC
* ^^^^^^^^^^^^^^^^
*
* crash> rd 0xffff8dee0312c198
* ffff8dee0312c198: 0000000000000000 ........
* ^^^^^^^^^^^^^^^^
*
* With the patch:
* crash> bt -v
* PID: 28642 TASK: ffff8dee0312c180 CPU: 0 COMMAND: "insmod"
* possible stack overflow: ffff991340bc0000: ffffffffc076400a != STACK_END_MAGIC
*
* crash> rd 0xffff991340bc0000
* ffff991340bc0000: ffffffffc076400a .@v.....
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 70a27ae9f2b45d6dba56ee4240b6adf79c544ee1
* Author: Lianbo Jiang <email address hidden>
* Date: Thu Jan 6 22:34:26 2022 +0800
*
* Fix for "timer -r" option to display all the per-CPU clocks
*
* Currently, the hrtimer_max_clock_bases is hard-coded to 3, which
* makes that crash only prints three clocks, and the rest of clocks
* are not displayed.
*
* Without the patch:
* crash> timer -r -C 11
* CPU: 11 HRTIMER_CPU_BASE: ffff9a775f95ee00
* CLOCK: 0 HRTIMER_CLOCK_BASE: ffff9a775f95ee80 [ktime_get]
* (empty)
*
* CLOCK: 1 HRTIMER_CLOCK_BASE: ffff9a775f95ef00 [ktime_get_real]
* (empty)
*
* CLOCK: 2 HRTIMER_CLOCK_BASE: ffff9a775f95ef80 [ktime_get_boottime]
* (empty)
*
* With the patch:
* crash> timer -r -C 11
* CPU: 11 HRTIMER_CPU_BASE: ffff9a775f95ee00
* CLOCK: 0 HRTIMER_CLOCK_BASE: ffff9a775f95ee80 [ktime_get]
* (empty)
*
* CLOCK: 1 HRTIMER_CLOCK_BASE: ffff9a775f95ef00 [ktime_get_real]
* (empty)
*
* CLOCK: 2 HRTIMER_CLOCK_BASE: ffff9a775f95ef80 [ktime_get_boottime]
* (empty)
* ...
* CLOCK: 7 HRTIMER_CLOCK_BASE: ffff9a775f95f200 [ktime_get_clocktai]
* (empty)
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 98b417fc63467339b919ef6d322c1893d6d55f86
* Author: Lianbo Jiang <email address hidden>
* Date: Fri Dec 24 18:56:35 2021 +0800
*
* Handle blk_mq_ctx member changes for kernels 5.16-rc1 and later
*
* Kernel commit 9a14d6ce4135 ("block: remove debugfs blk_mq_ctx
* dispatched/merged/completed attributes") removed the member
* rq_dispatched and rq_completed from struct blk_mq_ctx. Without
* the patch, "dev -d|-D" options will fail with the following error:
*
* crash> dev -d
* MAJOR GENDISK NAME REQUEST_QUEUE TOTAL ASYNC SYNC
*
* dev: invalid structure member offset: blk_mq_ctx_rq_dispatched
* FILE: dev.c LINE: 4229 FUNCTION: get_one_mctx_diskio()
*
* Signed-off-by: Lianbo Jiang <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 7eba220e1a7d443cad6716dd83d4953ffd62d566
* Author: Qi Zheng <email address hidden>
* Date: Tue Dec 21 15:40:31 2021 +0800
*
* Fix pvops Xen detection for arm machine
*
* Since the xen_start_info on the arm/arm64 platform points to a static
* variable '_xen_start_info'(see its definition as below), which makes
* that the address of xen_start_info will never be null.
*
* arch/arm/xen/enlighten.c:40:static struct start_info _xen_start_info;
* arch/arm/xen/enlighten.c:41:struct start_info *xen_start_info = &_xen_start_info;
* arch/arm/xen/enlighten.c:42:EXPORT_SYMBOL(xen_start_info);
*
* As a result, the is_pvops_xen() in commit 4badc6229c69 ("Fix pvops
* Xen detection for kernels >= v4.20") always returns TRUE because it
* can always read out the non-null address of xen_start_info, finally
* the following error will be reported on arm/arm64 platform(non-Xen
* environment) because p2m_mid_missing and xen_p2m_addr are not defined:
*
* crash: cannot resolve "p2m_top"
*
* For the arm/arm64 platform, fix it by using xen_vcpu_info instead of
* xen_start_info to detect Xen dumps.
*
* In addition, also explicitly narrow the scope of the xen_start_info
* check to x86 with the machine_type(), there is no need to check it on
* other architectures.
*
* Fixes: 4badc6229c69 ("Fix pvops Xen detection for kernels >= v4.20")
* Signed-off-by: Qi Zheng <email address hidden>
* Acked-by: Kazuhito Hagio <email address hidden>
*
* commit 6968345893178d2750b8872055498d2a6010a861
* Author: HATAYAMA Daisuke <email address hidden>
* Date: Wed Dec 8 12:07:34 2021 +0000
*
* defs.h: fix breakage of compatibility of struct symbol_table_data for extension modules
*
* Commit <2fab8fbc0c4f> ("symbols: Implement install and remove operations
* for mod_symname_hash") added new member variable mod_symname_hash in the
* middle of struct symbol_table_date, which breaks compatibility of struct
* symbol_table_data for extension modules. As the result, crash trace command
* results in segmentation fault.
*
* Fixes: 2fab8fbc0c4f ("symbols: Implement install and remove operations for mod_symname_hash")
* Signed-off-by: HATAYAMA Daisuke <email address hidden>
*
* commit c477b04aee34d4f4784c326ed715e91b2c43eb3e
* Author: HATAYAMA Daisuke <email address hidden>
* Date: Thu Dec 9 01:05:07 2021 +0000
*
* defs.h: fix breakage of compatibility of struct machdep_table for extension modules
*
* Commit <2f967fb5ebd7> ("crash_taget: fetch_registers support") added new
* member get_cpu_reg in the middle of struct machdep_table, which breaks
* compatibility of struct machdep_table for extension modules. As the result,
* crash gcore command results in unexpected behavior, furthermore may cause
* segmentation fault.
*
* Fixes: 2f967fb5ebd7 ("crash_taget: fetch_registers support")
* Signed-off-by: HATAYAMA Daisuke <email address hidden>
*
* commit 995db8ab88916b6397676b67be98c0a4f82cca49
* Author: Hong YANG <email address hidden>
* Date: Mon Nov 15 15:41:01 2021 +0800
*
* arm64: Support overflow stack panic
*
* Kernel commit <872d8327ce89> ("arm64: add VMAP_STACK overflow detection")
* has supported the overflow stack exception handling. Without the patch, the
* "bt" command will make crash generate a core dump because of segmentation
* fault. With the patch, the "bt" command can display the overflow stack.
*
* Before:
* crash> bt
* PID: 3607 TASK: ffffffcbf9a4da00 CPU: 2 COMMAND: "sh"
* Segmentation fault (core dumped)
*
* After:
* crash> bt
* PID: 3607 TASK: ffffffcbf9a4da00 CPU: 2 COMMAND: "sh"
* #0 [ffffffccbfd85f50] __delay at ffffff8008ceded8
* ...
* #5 [ffffffccbfd85fd0] emergency_restart at ffffff80080d49fc
* #6 [ffffffccbfd86140] panic at ffffff80080af4c0
* #7 [ffffffccbfd86150] nmi_panic at ffffff80080af150
* #8 [ffffffccbfd86190] handle_bad_stack at ffffff800808b0b8
* #9 [ffffffccbfd862d0] __bad_stack at ffffff800808285c
* PC: ffffff8008082e80 [el1_sync]
* LR: ffffff8000d6c214 [stack_overflow_demo+84]
* SP: ffffff1a79930070 PSTATE: 204003c5
* X29: ffffff8011b03d00 X28: ffffffcbf9a4da00 X27: ffffff8008e02000
* X26: 0000000000000040 X25: 0000000000000124 X24: ffffffcbf9a4da00
* X23: 0000007daec2e288 X22: ffffffcbfe03b800 X21: 0000007daec2e288
* X20: 0000000000000002 X19: 0000000000000002 X18: 0000000000000002
* X17: 00000000000003e7 X16: 0000000000000000 X15: 0000000000000000
* X14: ffffffcc17facb00 X13: ffffffccb4c25c00 X12: 0000000000000000
* X11: ffffffcc17fad660 X10: 0000000000000af0 X9: 0000000000000000
* X8: ffffff1a799334f0 X7: 0000000000000000 X6: 000000000000003f
* X5: 0000000000000040 X4: 0000000000000010 X3: 00000065981d07f0
* X2: 00000065981d07f0 X1: 0000000000000000 X0: ffffff1a799334f0
*
* Signed-off-by: Hong YANG <email address hidden>
*
* commit d9b11ddd19e98424b54bef4260b9d780f869b504
* Author: Lianbo Jiang <email address hidden>
* Date: Wed Dec 1 17:36:20 2021 +0800
*
* Mark start of 8.0.1 development phase with version 8.0.0++
*
* Signed-off-by: Lianbo Jiang <email address hidden>
-- Matthias Klose <email address hidden> Thu, 06 Jul 2023 16:49:16 +0200
crash (8.0.0-1ubuntu1) jammy; urgency=medium
* Merge with Debian; remaining changes:
- Build without lto. Fails to build gdb on ppc64el. That should be fixed,
once gdb is updated to a more recent version (e.g. 10.x).
- Add linux-libc-dev dependency for the autopkg test. This package
gets usually broken with kernel upgrades, so let it already show
in the autopkg test.
* Run autopkg test with allow-stderr.
crash (8.0.0-1) unstable; urgency=medium
* New upstream (Closes: #950544)
* Add lintian override for zlib in embedded gdb
*
* commit ec568e2ea515b66343d3488d5d4b9a625d55b7ae
* Author: Kazuhito Hagio <email address hidden>
* Date: Wed Nov 24 13:32:49 2021 +0900
*
* crash-7.3.0 -> crash-8.0.0
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 6bc104059b124ecac5c8244f84aae6d7cfdfe97c
* Author: Kazuhito Hagio <email address hidden>
* Date: Tue Nov 16 02:42:23 2021 +0000
*
* log: add warning to help text to inform the inaccuracy of -T option
*
* The timestamps of the "log -T" option are inaccurate because they are
* from local_clock(), which returns the raw counter in the local CPU and
* it's different from the elapsed wall time.
*
* The dmesg command, which the "log -T" option imitates, has a similar
* behavior in nature and a warning in its help text. Let's add a warning
* also to the crash's help text to inform the inaccuracy for now.
*
* Reported-by: Martin Moore <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit b0dd73d2368275e101688b2aca0bc297fd1ba300
* Author: Aaron Tomlin <email address hidden>
* Date: Mon Nov 1 11:39:34 2021 +0000
*
* kernel: show that the kernel is tainted at init-time
*
* Explicitly indicate to the user that the Linux kernel is tainted
* at init-time or when the 'sys' command is used.
*
* Signed-off-by: Aaron Tomlin <email address hidden>
*
* commit 64f48ee6719632895cd8a0922e84a4626e3790d8
* Author: Aaron Tomlin <email address hidden>
* Date: Mon Nov 1 11:39:33 2021 +0000
*
* kernel: Introduce is_kernel_tainted()
*
* Provide a quick way to test if the given Linux kernel is "tainted".
* Support for Linux-2.6.12 and above, to date.
*
* Signed-off-by: Aaron Tomlin <email address hidden>
*
* commit bfa596f40650e5a061b15d41b0a5b108610b11e9
* Author: Aaron Tomlin <email address hidden>
* Date: Mon Nov 1 11:39:32 2021 +0000
*
* kernel: consolidate show_kernel_taints()
*
* No functional change.
*
* Signed-off-by: Aaron Tomlin <email address hidden>
*
* commit 8246dce99dd23457e8c7a3fe9609c706694d1959
* Author: Kazuhito Hagio <email address hidden>
* Date: Thu Nov 11 15:20:52 2021 +0900
*
* arm64: Update SECTION_SIZE_BITS for kernels >= 5.12
*
* Update the default SECTION_SIZE_BITS value for arm64 Linux 5.12
* and later kernels that contain kernel commit f0b13ee23241
* ("arm64/sparsemem: reduce SECTION_SIZE_BITS").
*
* Reported-by: Ankur Bansal <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 01d20ca1861ffaf449c1c60aa0536e9f42200ad3
* Author: Philipp Rudo <email address hidden>
* Date: Tue Nov 9 14:52:22 2021 +0100
*
* Fix live debugging with lockdown=integrity
*
* With kernel lockdown the access to kernel interfaces that allow one to
* extract confidential information (lockdown=confidentiality) or modify a
* running kernel (lockdown=integrity) can be restricted. Two of the
* interfaces that can be restricted are /dev/mem (integrity &
* confidentiality) and /proc/kcore (confidentiality). With
* lockdown=integrity this leads to a situation where /dev/mem exists but
* is not readable while /proc/kcore exists and is readable. This breaks
* crash's live debugging when it is invoked without argument, i.e.
*
* $ crash
* [...]
* crash: /dev/mem: Operation not permitted
*
* while passing /proc/kcore as image succeeds. The reason for this is
* that crash always picks /dev/mem as source when it exits but doesn't
* check if it is readable. Fix this by only selecting /dev/mem when it
* is readable.
*
* Signed-off-by: Philipp Rudo <email address hidden>
*
* commit 68870c83d299603c07785e3530e33c13045c87ef
* Author: Alexander Egorenkov <email address hidden>
* Date: Wed Oct 13 10:56:39 2021 +0200
*
* Handle task_struct cpu member changes for kernels >= 5.16-rc1
*
* Kernel commit bcf9033e5449bdcaa9bed46467a7141a8049dadb
* ("sched: move CPU field back into thread_info if THREAD_INFO_IN_TASK=y")
* moved the member cpu of task_struct back into thread_info.
* Without the patch, crash fails with the following error message
* during session initialization:
*
* crash: invalid structure member offset: task_struct_cpu
* FILE: task.c LINE: 2904 FUNCTION: add_context()
*
* Signed-off-by: Alexander Egorenkov <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit c180a63f2cb370da6097ad97eb07333c07aa988b
* Author: Kazuhito Hagio <email address hidden>
* Date: Mon Oct 25 16:53:26 2021 +0900
*
* arm64: Use VA_BITS for page_offset calculation
*
* Commit 167d37e347fe ("arm64: assign page_offset with VA_BITS kernel
* configuration value") changed the page_offset calculation from
* using VA_BITS_ACTUAL to CONFIG_ARM64_VA_BITS. This caused an error
* for ramdumps without vmcoreinfo like this:
*
* crash: vmlinux and /var/tmp/ramdump_elf_XUtCMT do not match!
*
* Set the vmcoreinfo value to VA_BITS if available, and use VA_BITS
* for page_offset calculation instead.
*
* Also remove ARM64_FLIP_PAGE_OFFSET_ACTUAL because it's not used
* actually.
*
* Reported-by: Ankur Bansal <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 5c04a6f3f923af7c50f0d853477044802b3fa6ec
* Author: Tao Liu <email address hidden>
* Date: Sat Oct 16 13:21:17 2021 +0800
*
* symbols: Add mod_symname_hash table dump to help -s
*
* Previously, help -s only print out the dump status of symname_hash
* table. Since we have mod_symname_hash table introduced, let's print
* out mod_symname_hash in help -s as well.
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit df0049d12b2ced1b6ff7350ee3c0ca28c3f7cd52
* Author: Tao Liu <email address hidden>
* Date: Sat Oct 16 13:21:16 2021 +0800
*
* symbols: Refactor SYMNAME_HASH_INDEX macro to be a function
*
* SYMNAME_HASH_INDEX is used as the index of symname hash table. It will
* be out of range if SYMNAME_HASH_INDEX is negative. This patch avoids
* the risk by changing the marco into a function, and casting and
* calculating the numbers as unsigned.
*
* Suggested-by: Lianbo Jiang <email address hidden>
* Suggested-by: Philipp Rudo <email address hidden>
* Signed-off-by: Tao Liu <email address hidden>
*
* commit 1e23335dab6bf9f6219a23bf0be4ad9f433f4f43
* Author: Tao Liu <email address hidden>
* Date: Sat Oct 16 13:21:15 2021 +0800
*
* symbols: Sync module symbols into mod_symtable whenever module symbols
* change
*
* Signed-off-by: Tao Liu <email address hidden>
* Reviewed-by: Philipp Rudo <email address hidden>
*
* commit f3bee9375ed32b85e7f81a5e46a0040620553ae0
* Author: Tao Liu <email address hidden>
* Date: Sat Oct 16 13:21:14 2021 +0800
*
* symbols: Intergrate symbol_exists() with mod_symname_hash search
*
* This patch introduces mod_symname_hash search to symbol_exists()
* to improve its performance. And code refactoring for
* kernel_symbol_exists().
*
* Signed-off-by: Tao Liu <email address hidden>
* Reviewed-by: Philipp Rudo <email address hidden>
*
* commit 340c6ad1a0a7ce76eb5d9397833bfc6a049e2b3b
* Author: Tao Liu <email address hidden>
* Date: Sat Oct 16 13:21:13 2021 +0800
*
* symbols: Extend symname_hash_search() with hash table select
*
* Previously symname_hash_search() can only search symbols from kernel's
* symname_hash. This patch add hash table pointer as parameter for
* symname_hash_search(). Thus symname_hash_search() can be used both for
* symname_hash and mod_symname_hash searching.
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit 214f9bf3727c3350401b3f4b4389258c24486e06
* Author: Tao Liu <email address hidden>
* Date: Sat Oct 16 13:21:12 2021 +0800
*
* symbols: Integrate symbol_search() with mod_symname_hash search
*
* This patch introduces mod_symname_hash search to symbol_search(),
* to get a better searching performance.
*
* Signed-off-by: Tao Liu <email address hidden>
* Reviewed-by: Philipp Rudo <email address hidden>
*
* commit 2fab8fbc0c4f1c4cbe889de4cead5f7457a19f77
* Author: Tao Liu <email address hidden>
* Date: Sat Oct 16 13:21:11 2021 +0800
*
* symbols: Implement install and remove operations for mod_symname_hash
*
* Currently the sequence for symbol_search to search a symbol is: 1)
* kernel symname hash table, 2) iterate all kernel symbols, 3) iterate
* all kernel modules and their symbols. In the worst case, if a
* non-exist symbol been searched, all 3 stages will be went through. The
* time consuming status for each stage is like:
*
* stage 1 stage 2 stage 3
* 0.007000(ms) 0.593000(ms) 2.421000(ms)
*
* stage 3 takes too much time when comparing to stage 1. This patch
* series introduces a symname hash table for kernel modules, to improve
* the performance of symbol searching.
*
* Functions symbol_search() and symbol_exists() are fundamental and
* widely used by other crash functions, thus the benefit of performance
* improvement can get accumulated. For example, "ps -m" and "irq"
* commands, which call the functions many times, will become faster with
* the patch series.
*
* This patch indroduces mod_symname_hash, and its install/remove
* operations. Since symbol_search() has to return the lowest address
* symbol and symbol_search_next() returns the next lowest symbol, thus
* the installation should be sorted ascendingly.
*
* In mod_symname_hash_install_range() scenario, spn are already arranged
* ascendingly, so for mod_symname_hash_install():
*
* Install spn previous to sp:
*
* If sp is the start of bucket, or
* 1) spn->value is smaller than sp->value.
*
* Install spn next to sp:
*
* 1) sp->name_hash_next is NULL, or
* 2) sp->name_hash_next->value is larger than spn->value
*
* spn->value is the kernel address of the symbol and will not change.
* So we use it mainly to determine the sequence. When spn->value equals
* sp->value, they must be symbols within a kernel module.
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit f7e3b2d9b753793e230a5242974a111cdf139e49
* Author: Kazuhito Hagio <email address hidden>
* Date: Thu Sep 30 11:04:31 2021 +0900
*
* .gitignore: add gdb-10.2 directory
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 05a3a328fcd8920e49926b6d1c9c81ce0b6acbca
* Author: Kazuhito Hagio <email address hidden>
* Date: Thu Sep 9 15:23:27 2021 +0900
*
* Remove text value cache code
*
* The text value cache was implemented for analysis of remote dumpfiles
* using the deprecated "crash daemon" running on the remote host. On
* updating GDB to 10.2, a regression occurred when we tried to fix a
* "help -x" command problem, and there was no performance degradation
* even without the text cache, so let's drop this functionality.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit c1e256249426dd59ceea99038451a39e98a26790
* Author: Kazuhito Hagio <email address hidden>
* Date: Thu Aug 19 10:52:58 2021 +0900
*
* Fix tab completion issues
*
* 1. The maximum number of tab completion candidates is limited to 200
* by default. Set it unlimited.
*
* 2. The output of tab completion is not wrapped with the screen width.
* Get and use it when tab completion is invoked.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 5c2d8d2d9da6423eec076fd51049d7b4677b61c6
* Author: Tao Liu <email address hidden>
* Date: Tue Aug 17 16:21:43 2021 +0800
*
* Set gdb max-value-size to be unlimited
*
* gdb-10.2 uses max-value-size as the maximum size in bytes that the
* contents of a object may allocate. The default value of max-value-size
* is 64K. However, it could be not enough for allocating an object which
* requires larger space, and failed at the startup of crash.
*
* In gdb-7.6, there is no max-value-size check and works fine. So in
* this patch, let's just set max-value-size to be unlimited.
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit b8e1f2735b8dd1303aeb2affa309a2a409a82d38
* Author: Tao Liu <email address hidden>
* Date: Mon Jul 26 09:58:54 2021 +0800
*
* Add kernel version dependent check for getting length of log_end
*
* For kernels(>=2.4.9.11 [1] && <3.5 [2]), log_end was involved in the
* kernel sources.
* For kernels(>=2.6.25 [3]), log_end was defined as:
* static unsigned log_end;
* For kernels(<2.6.25), log_end was defined as:
* static unsigned long log_end;
*
* Previously, the length of log_end is determined by get_symbol_length,
* but it can be a regression when the returned length is 0 for some
* cases and value unchecked:
*
* crash> help -t
* ...
* help: invalid size request: 0 type: "log_end"
*
* To solve the above issue, let's add a kernel version dependent check
* to get its value appropriately when the length of the 'log_end'
* returns a value of zero.
*
* [1]: https://elixir.bootlin.com/linux/2.4.9.11/source/kernel/printk.c#L74
* [2]: https://elixir.bootlin.com/linux/v3.5/source/kernel/printk.c
* [3]: https://elixir.bootlin.com/linux/v2.6.25/source/kernel/printk.c#L104
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit 51f21b0d1c91a4ae02ebf0d8c81460ec8b6c1283
* Author: Tao Liu <email address hidden>
* Date: Thu Jul 15 17:34:29 2021 +0800
*
* x86_64_irq_eframe_link_init: Fix wrong instruction searching range
* calculation
*
* In function x86_64_irq_eframe_link_init, instruction "push xxx" is
* searched in addresses range from "common_interrupt" to the next nearby
* symbol, in order to calculate the value of irq_eframe_link. The
* searching distance is given by max_instructions, which is calculated
* by end ranging address minus start ranging address. Then crash asks
* gdb to disassemble max_instructions quantity of instructions.
*
* Taking max_instructions as the quantity of disassemble instructions is
* inappropriate, because most x86_64 instructions have a length longer
* than 1, as a consequence, much more than the actual needed
* instructions get disassembled.
*
* In gdb-7.6 crash, the extra instructions are skipped by
* "if (!strstr(buf, sp->name))", which breaks if one instruction doesn't
* belongs to a symbol:
*
* 0xffffffff8005d5b4 <common_interrupt+0>: cld
* 0xffffffff8005d5b5 <common_interrupt+1>: sub $0x48,%rsp
* ...
* 0xffffffff8005d61e <common_interrupt+106>: leaveq
* 0xffffffff8005d61f <exit_intr>: mov %gs:0x10,%rcx
* <--- searching stops here
* ...
*
* In gdb-10.2 crash, "exit_intr" doesn't show, however it really exist.
* As a result, searching for "push xxx" will go to a wrong place.
*
* 0xffffffff8005d5b4 <common_interrupt+0>: cld
* 0xffffffff8005d5b5 <common_interrupt+1>: sub $0x48,%rsp
* ...
* 0xffffffff8005d61e <common_interrupt+106>: leave
* 0xffffffff8005d61f <common_interrupt+107>: mov %gs:0x10,%rcx
* <--- searching continues
* ...
*
* (gdb) p exit_intr
* $1 = {<text variable, no debug info>} 0xffffffff8005d61f
* <common_interrupt+107>
* (gdb) info symbol exit_intr
* common_interrupt + 107 in section .text
*
* The previous way to determine start and end searching range is not
* stable, otherwise we may encounter regression that cmd "bt" prints
* wrong IRQ stack. This patch fix the bug by removing max_instructions
* calculation, and directly ask gdb to disassemble addresses range from
* "common_interrupt" to the next nearby symbol.
*
* Signed-off-by: Tao Liu <email address hidden>
*
* commit fce91bec5bef534e52f3261cc289a21a2cdb5fe3
* Author: Tao Liu <email address hidden>
* Date: Sun Jul 11 22:30:22 2021 +0800
*
* Fix the failure of reporting vmcore and vmlinux do not match for
* kernels(<2.6.11)
*
* There is a regression issue for kernels(<2.6.11) as below:
*
* $ crash 2.6.9-68.9/vmcore 2.6.9-68.9/vmlinux.gz
* ...
* GNU gdb (GDB) 10.2
* ...
* crash: /var/tmp/vmlinux.gz_GLsAvX and 2.6.9-68.9/vmcore do not match!
*
* The reason is that it needs to read out the address of linux banner
* with readmem() first, and then the read_string() will be able to read
* the data from linux banner. So, for the kernels(<2.6.11) case, lets
* still invoke get_symbol_data() to accomplish this. See the changes:
* [1] https://elixir.bootlin.com/linux/v2.6.10/source/init/version.c#L38
* [2] https://elixir.bootlin.com/linux/v2.6.11/source/init/version.c#L38
*
* Signed-off-by: Tao Liu <email address hidden>
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 8d6f677e54a2474b3da19402e29278b62603d71d
* Author: Alexey Makhalov <email address hidden>
* Date: Thu Jul 8 16:14:02 2021 -0700
*
* Do not adjust addr by relocate offset(KASLR)
*
* GBD symbol resolution already considers relocation (KASLR) offset.
* So, there is no needs to adjust the function address before calling
* GDB.
*
* It fixes file name and line number output for 'dis -l' and 'sys -c'
* commands.
*
* Signed-off-by: Alexey Makhalov <email address hidden>
* Signed-off-by: Tao Liu <email address hidden>
*
* commit 6c5f0c6ff5d158f2ef4fa997a052b0643d0c25ee
* Author: Alexey Makhalov <email address hidden>
* Date: Fri Mar 19 21:07:36 2021 -0700
*
* vmware_guestdump: add debugging of the init function
*
* Dump memory and registers state after parsing.
*
* Signed-off-by: Alexey Makhalov <email address hidden>
*
* commit 96716862765f73676bfdb2d19fc5872364d21b73
* Author: Alexey Makhalov <email address hidden>
* Date: Fri Mar 19 21:07:35 2021 -0700
*
* vmware backend: honor silence flag
*
* Do not print any boot messages in silence (-s) mode.
*
* Signed-off-by: Alexey Makhalov <email address hidden>
*
* commit e832e0eb5bd8d97dfa9f4bd0e22fbfad849c11df
* Author: Alexey Makhalov <email address hidden>
* Date: Fri Mar 19 21:07:34 2021 -0700
*
* Allow 'gdb disassemble' command for relocated kernel
*
* As new gdb is able to handle it properly.
*
* Signed-off-by: Alexey Makhalov <email address hidden>
*
* commit 2f967fb5ebd737ce5eadba462df35935122e8865
* Author: Alexey Makhalov <email address hidden>
* Date: Fri Mar 19 21:07:33 2021 -0700
*
* crash_taget: fetch_registers support
*
* Provides API for crash_target to fetch registers of given
* CPU. It will allow gdb to perform such commands as "bt",
* "frame", "info locals".
*
* Highlevel API is crash_get_cpu_reg (). It calls machine
* (architecture) specific function: machdep->get_cpu_reg().
* Input arguments such as register number and register size
* come from gdb arch information. So, get_cpu_regs()
* implementations in crash must understand it.
*
* Signed-off-by: Alexey Makhalov <email address hidden>
*
* commit 0b85218983ffcf939a638f1133871079c5615a46
* Author: Alexey Makhalov <email address hidden>
* Date: Fri Mar 19 21:07:30 2021 -0700
*
* Fix reduced output of `bt` command
*
* gdb-10 produces reduced output of `bt` command.
*
* Changed disassembler output is the reason of missing frames
* in backtrace. Call instruction mnemonic for x86_64 was changed
* from "callq" to "call" in gdb-10.
*
* Fixing the issue by adding a search for "call" word in disassembler
* parser.
*
* Signed-off-by: Alexey Makhalov <email address hidden>
* Reported-by: Kazuhito Hagio <email address hidden>
*
* commit 36e9d8673e9205f4ea4daad61c199597920c93df
* Author: Alexey Makhalov <email address hidden>
* Date: Fri Mar 19 21:07:27 2021 -0700
*
* "whatis -m": fix duplications in the output
*
* "whatis -m" output started to generate duplicated results after GDB
* update:
*
* crash> whatis -m mm_struct
* SIZE TYPE
* 16 tlb_state
* ...
* 256 linux_binprm
* 2752 rq
* 2752 rq <<-- duplicated
* 2752 rq
* 2752 rq
* 2752 rq
* 4048 task_struct
*
* It was caused by incorrect string comparisons.
* Use strcmp for full string comparison instead of just string pointers
* comparison.
*
* Signed-off-by: Alexey Makhalov <email address hidden>
* Reported-by: Kazuhito Hagio <email address hidden>
*
* commit 163abcbbabdf8207c11ee93b1c909d85ecbcbf1f
* Author: Alexey Makhalov <email address hidden>
* Date: Fri Mar 19 21:07:26 2021 -0700
*
* crash_get_nr_cpus: get nr_cpus from the dumps
*
* Most of the dumps have information about real number of CPUS.
* Use that to instantiate GDB's target inferior threads.
*
* Signed-off-by: Alexey Makhalov <email address hidden>
*
* commit 9fab193edb34ddf30282b5ac137f7d8078198938
* Author: Alexey Makhalov <email address hidden>
* Date: Tue Aug 17 17:14:59 2021 +0800
*
* Update to gdb-10.2
*
* Main changes:
* [1] update gdb-7.6.patch to gdb-10.2.patch, and keep all functionality
* and good compatibility
* [2] remove unneeded patches(gdb-7.6-proc_service.h.patch and
* gdb-7.6-ppc64le-support.patch)
* [3] to make the c++ compiler happy, add the extern "C" to eliminate
* compilation issues, also add CXXFLAGS=-m32 to generate proper
* 32bit object files
* [4] the parameter types of some functions are changed, eg, the set of
* prettyprint variables
* [5] eliminate error_hook() and SJLJ while running in C++ code (after
* gdb_command_funnel()) use try-catch mechanism instead
* [6] request_types() is redone to do not call GNU_GET_NEXT_DATATYPE
* multiple times but single usage of GNU_ITERATE_DATATYPES with proper
* callback instead. Complete iteration happens on C++ side now.
* [7] remove "struct global_iterator" from request structure, but add
* several fields (including callback pointer) to be able to perform
* iteration on C++ side
* [8] type of "linux_banner" symbol is reported as 'D' by new gdb as its
* section ".rodata" marked as writable in vmlinux
* [9] BFD API has changed.
* [10] the deprecated_command_loop_hook got deprecated. So, call crash
* main_loop() directly from gdb captured_main()
* [11] remove previously used hooks for that in target.c. Add
* crash_target for gdb to provide target operations such as xfer_partial
* to read and write crash dump memory.
*
* Signed-off-by: Alexey Makhalov <email address hidden>
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit 7f38d1baf794823355ee100b3a1914155d4190f2
* Author: Kazuhito Hagio <email address hidden>
* Date: Mon Sep 27 09:45:42 2021 +0900
*
* diskdump: Add support for reading dumpfiles compressed by Zstandard
*
* Add support for reading dumpfiles compressed by Zstandard (zstd)
* using makedumpfile.
*
* To build crash with zstd support, type "make zstd".
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit cf0c8d10e1870d89b39f40382634db51aa8fcf2c
* Author: Hari Bathini <email address hidden>
* Date: Fri Sep 3 17:33:42 2021 +0530
*
* mod: fix module object file lookup
*
* On systems where vmlinux file is not under /usr/lib/debug/lib/modules
* directory, 'mod -s|-S' command may fail to find the module's object
* file with the below error:
*
* mod: cannot find or load object file for sd_mod module
*
* Fix it by trying all possible module object file extensions while
* searching for the object file under /usr/lib/debug/lib/modules
* directory.
*
* Signed-off-by: Naveen N. Rao <email address hidden>
* Signed-off-by: Hari Bathini <email address hidden>
*
* commit 15765867c0f1d937db5ec06f51adb6bfd13354ea
* Author: Ritesh Harjani <email address hidden>
* Date: Thu Aug 26 02:31:10 2021 +0530
*
* ppc64: Add MMU type info in machdep command
*
* This adds MMU type info in "machdep" command.
*
* Signed-off-by: Ritesh Harjani <email address hidden>
*
* commit 3db5fff2e9d7b8762d1bd46d8d2c47ba4c7e374f
* Author: Ritesh Harjani <email address hidden>
* Date: Thu Aug 26 02:31:08 2021 +0530
*
* .gitignore: Add cscope, ctags & compile_commands.json
*
* Add cscope, ctags & compile_commands.json in .gitignore file.
*
* Signed-off-by: Ritesh Harjani <email address hidden>
*
* commit 4b34197508578bb43639e6d169fb91fb0489fa2b
* Author: James Hsu <email address hidden>
* Date: Wed Aug 18 15:45:47 2021 +0800
*
* arm64: Get CPU registers from ELF notes even without crash_notes symbol
*
* Currently arm64 crash retrieves the CPU registers from crash_notes symbol
* or ELF notes only when the symbol exists, but there are dumpfiles which
* have the registers in ELF notes without the symbol.
*
* With the patch, crash can retrieve the registers from ELF notes without
* the crash_notes symbol.
*
* Signed-off-by: James Hsu <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 44e5801d9016987b6b4ebd571bfde8ae3e75da7b
* Author: Philipp Rudo <email address hidden>
* Date: Thu Aug 5 15:19:37 2021 +0200
*
* x86_64: Fix check for __per_cpu_offset initialization
*
* Since at least kernel v2.6.30 the __per_cpu_offset gets initialized to
* __per_cpu_load. So first check if the __per_cpu_offset was set to a
* proper value before reading any per cpu variable to prevent potential
* bugs.
*
* [ kh: added check for the existence of __per_cpu_load ]
*
* Signed-off-by: Philipp Rudo <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 881f33d97cee9895796829d0cc969b51dd34d831
* Author: Roman Bolshakov <email address hidden>
* Date: Thu Jun 17 02:27:35 2021 +0300
*
* diskdump: Introduce read_pd()
*
* Standalone function for reading of page descriptors is needed later for
* of expected core size and detection of incomplete dumps.
*
* Signed-off-by: Roman Bolshakov <email address hidden>
*
* commit 1425b0504b1e79d88a2d188d7e4c0e7fceba4501
* Author: Roman Bolshakov <email address hidden>
* Date: Thu Jun 17 02:27:34 2021 +0300
*
* diskdump: Print total number of dumpable pages
*
* It's not clear how broken an incomplete dump from the existing debugging
* prints. Aggregate number of valid pages helps to figure out approximate
* size of the dump. Size of a complete dump is roughly:
*
* EXPECTED_CORE_SIZE = a few pages (kdump headers + bitmaps + descriptors)
* (total_valid_pages * block_size) * compression rate
*
* An incomplete core would be significantly smaller than:
*
* total_valid_pages * block_size
*
* Signed-off-by: Roman Bolshakov <email address hidden>
*
* commit 41cda195c6421fbde72ed67b32b8c1ab3eb0c56f
* Author: Roman Bolshakov <email address hidden>
* Date: Thu Jun 17 02:27:33 2021 +0300
*
* netdump: Permit --zero_excluded for incomplete ELF dumps
*
* DUMP_ELF_INCOMPLETE is set very late after ENOSPC error is hit by
* makedumpfile. Any following error that prevents modification of ELF
* header would result in effectively incomplete core that doesn't have the
* flag. zero_excluded flag doesn't work for such kind of incomplete core.
*
* Signed-off-by: Roman Bolshakov <email address hidden>
*
* commit 4631320e96f8a63c897fbbce4e87e3c47af40bc9
* Author: Roman Bolshakov <email address hidden>
* Date: Thu Jun 17 02:27:32 2021 +0300
*
* diskdump: Fail readmem() early if dump is incomplete
*
* kdump format description [1] says:
*
* [...] zero page has its own offset not equal 0. So when reading page
* from incomplete core, only the page lost by ENOSPACE errors has 0 in
* its corresponding page descriptor's member offset.
*
* crash has special treatment for page descriptors with zero offset only
* if DUMP_DH_COMPRESSED_INCOMPLETE is set in dump header. However,
* makedumpfile places the flag after ENOSPC is hit and only if dump
* header modification went without errors.
*
* In case if crashkernel environment was terminated early (e.g. by BMC)
* or some other reason, DUMP_DH_COMPRESSED_INCOMPLETE won't be set on
* the dump header. Then cache_page() would be performed on pages with
* pd.offset == 0 and due to pd.size == 0 it'll skip read into
* compressed_page and then non related pre-existing contents of
* compressed_page will copied into page cache for the non-present page.
*
* Ultimately, it'll lead to a cryptic failure, like:
*
* crash: invalid kernel virtual address: 72288cacacf427f8 [...]
*
* The failure would be a bit cleaner if crash explicitly fails on the
* page that is an outcome of incomplete dump:
*
* crash: page incomplete: kernel virtual address: c000003fff9d17e8 [...]
*
* Debugging level 8 would also produce exact offset from data_offset to
* print descriptor value with ease:
*
* read_diskdump/cache_page: descriptor with zero offset found at
* paddr/pfn/pos: 3fff9d0000/3fff9d/743dd
*
* That helps in inspecting broken descriptor with hexdump or similar
* tools:
*
* hexdump -s (data_offset + pos * 0x18) -n 0x18
*
* [1] https://github.com/makedumpfile/makedumpfile/
* blob/master/IMPLEMENTATION
*
* Signed-off-by: Roman Bolshakov <email address hidden>
*
* commit 80334ed25820cc08d147de5da361f427885cdd9e
* Author: Aaron Tomlin <email address hidden>
* Date: Tue Jul 13 14:24:49 2021 +0100
*
* kmem: Add support to -S option to specify a range of CPU-specific slab
* data
*
* With this patch, it is now possible for one to explicitly specify a
* range of CPU-specific slab data to list. For example:
*
* Note: This is only applicable to a Linux kernel with Kconfig
* CONFIG_SLUB enabled. The optional argument GNU extension
* for getopt(3) is utilized; and, the CPU range must be
* specified as expected
*
* crash> kmem -S=1,4 kmalloc-512
* CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
* ffff8d3f07c06c00 512 1916 3680 115 16k kmalloc-512
* CPU 1 KMEM_CACHE_CPU:
* ffff8d461fa6f140
* CPU 1 SLAB:
* SLAB MEMORY NODE TOTAL ALLOCATED FREE
* fffff540df7c4000 ffff8d45df100000 0 32 8 24
* FREE / [ALLOCATED]
* ffff8d45df100000 (cpu 1 cache)
* [ffff8d45df100200]
* ffff8d45df101000 (cpu 1 cache)
* ...skipped ...
* CPU 4 KMEM_CACHE_CPU:
* ffff8d461fb2f140
* CPU 4 SLAB:
* SLAB MEMORY NODE TOTAL ALLOCATED FREE
* fffff540dfde3800 ffff8d45f78e0000 0 32 8 24
* FREE / [ALLOCATED]
* [ffff8d45f78e0000]
* ffff8d45f78e0200 (cpu 4 cache)
* ffff8d45f78e0400 (cpu 4 cache)
* ...skipped ...
*
* Signed-off-by: Aaron Tomlin <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit f53b73e8380bca054cebd2b61ff118c46609429b
* Author: Pingfan Liu <email address hidden>
* Date: Fri Jul 2 10:14:24 2021 +0800
*
* arm64: implement switchable PTOV()/VTOP() for kernels >= 5.10
*
* Crash encounters a bug like the following:
* ...
* SECTION_SIZE_BITS: 30
* CONFIG_ARM64_VA_BITS: 52
* VA_BITS_ACTUAL: 48
* (calculated) VA_BITS: 48
* PAGE_OFFSET: ffff000000000000
* VA_START: ffff800000000000
* modules: ffff800008000000 - ffff80000fffffff
* vmalloc: ffff800010000000 - ffffffdfdffeffff
* kernel image: ffff800010000000 - ffff800012750000
* vmemmap: ffffffdfffe00000 - ffffffffffffffff
*
* <readmem: ffff800011c53bc8, KVADDR, "nr_irqs", 4, (FOE), b47bdc>
* <read_kdump: addr: ffff800011c53bc8 paddr: eb453bc8 cnt: 4>
* read_netdump: addr: ffff800011c53bc8 paddr: eb453bc8 cnt: 4
* offset: 1c73bc8
* irq_stack_ptr:
* type: 1, TYPE_CODE_PTR
* target_typecode: 8, TYPE_CODE_INT
* target_length: 8
* length: 8
* GNU_GET_DATATYPE[thread_union]: returned via gdb_error_hook
* <readmem: ffff000b779c0050, KVADDR, "IRQ stack pointer", 8, (ROE),
* 3a37bea0>
* <read_kdump: addr: ffff000b779c0050 paddr: fff1000bf79c0050 cnt: 8>
* read_netdump: READ_ERROR: offset not found for paddr:
* fff1000bf79c0050
* crash: read error: kernel virtual address: ffff000b779c0050 type:
* "IRQ stack pointer"
* ...
*
* Apparently, for a normal system, the 'paddr: fff1000bf79c0050' is
* unreasonable.
*
* This bug connects with kernel commit 7bc1a0f9e176 ("arm64: mm: use
* single quantity to represent the PA to VA translation"), which removed
* physvirt_offset kernel variable and changed the PTOV()/VTOP() formulas.
*
* Implement switchable PTOV()/VTOP() to cope with different kernel
* version.
*
* Signed-off-by: Pingfan Liu <email address hidden>
*
* commit bf1379a8b6ff8d6a8fa12978f7194f15f85c4380
* Author: Pingfan Liu <email address hidden>
* Date: Fri Jul 2 10:14:23 2021 +0800
*
* arm64: use dedicated bits to record the VA space layout changes
*
* arm64 memory layout experiences big changes due to the following kernel
* commits in date descending order:
* 5. 7bc1a0f9e176 arm64: mm: use single quantity to represent the PA
* to VA translation
* 4. b6d00d47e81a arm64: mm: Introduce 52-bit Kernel VAs
* 3. 5383cc6efed1 arm64: mm: Introduce vabits_actual
* 2. 14c127c957c1 arm64: mm: Flip kernel VA space
* 1. f80fb3a3d508 arm64: add support for kernel ASLR
*
* For 1, crash has already used NEW_VMEMMAP to trace it.
* For 2, crash lacks a flag to tag it and handle it differently.
* For 3, two important kernel variables vabits_actual and physvirt_offset
* are introduced.
* For 4, since it comes immediately after 3, crash-utility does not need
* to distinguish it.
* For 5, kernel variable phyvirt_offset is removed
*
* These changes have effects on PTOV()/VTOP() formula. So introducing
* two bits HAS_PHYSVIRT_OFFSET and FLIPPED_VM as hint to apply different
* formula.
*
* Signed-off-by: Pingfan Liu <email address hidden>
*
* commit 167d37e347fe35c6f7db826e8539e192c4375564
* Author: Pingfan Liu <email address hidden>
* Date: Fri Jul 2 10:14:22 2021 +0800
*
* arm64: assign page_offset with VA_BITS kernel configuration value
*
* On RHEL9, crash hits a bug when executing "crash /proc/kcore":
* seek error: kernel virtual address: ffff6a0f3fff0000 type: "pmd page"
*
* The kernel virtual address does not vary with vabits_actual, instead,
* is determined by configuration value. But crash does not observe this
* fact.
*
* Since vabits_actual related kernel commit is introduced after arm64
* mm layout flip commit, so changes are safe under the condition if
* (ms->VA_BITS_ACTUAL), and keep the else branch untouched.
*
* Signed-off-by: Pingfan Liu <email address hidden>
*
* commit 5719afc7a40868418405a87a2711088556e68a3b
* Author: Pingfan Liu <email address hidden>
* Date: Fri Jul 2 10:14:21 2021 +0800
*
* arm64: rename ARM64_PAGE_OFFSET_ACTUAL to ARM64_FLIP_PAGE_OFFSET_ACTUAL
*
* Reflect the flipped layout of kernel VA, which is introduced by
* kernel commit 14c127c957c1 ("arm64: mm: Flip kernel VA space").
*
* Signed-off-by: Pingfan Liu <email address hidden>
*
* commit d6b4f36d6b22b70fb14e692f36d20910ef5563c1
* Author: Alexander Egorenkov <email address hidden>
* Date: Tue Jun 29 08:39:00 2021 +0200
*
* Handle task_struct state member changes for kernels >= 5.14-rc1
*
* Kernel commit 2f064a59a11ff9bc22e52e9678bc601404c7cb34 ("sched: Change
* task_struct::state") renamed the member state of task_struct to __state
* and its type changed from long to unsigned int. Without the patch,
* crash fails to start up with the following error:
*
* crash: invalid structure member offset: task_struct_state
* FILE: task.c LINE: 5929 FUNCTION: task_state()
*
* Signed-off-by: Alexander Egorenkov <email address hidden>
*
* commit 4badc6229c69f5cd9da7eb7bdf400a53ec6db01a
* Author: Petr Tesařík <email address hidden>
* Date: Fri Jun 25 17:21:18 2021 +0200
*
* Fix pvops Xen detection for kernels >= v4.20
*
* Kernel commit 5c83511bdb9832c86be20fb86b783356e2f58062 removed
* pv_init_ops, and later commit 054ac8ad5ebe4a69e1f0e842483821ddbe560121
* removed the Xen-specific paravirt patch function. As a result, pvops Xen
* dumps are no longer recognized as Xen dumps, and virtual-to-physical
* translation fails.
*
* Use the value of xen_start_info to determine whether the kernel is
* running in Xen PV mode. This pointer is set during the initialization of
* a PV domain. Kudos to Juergen Gross, who suggested this check.
*
* Signed-off-by: Petr Tesarik <email address hidden>
*
* commit eaf14f852ae79f7745934e213661f1c6abac711e
* Author: Greg Edwards <email address hidden>
* Date: Wed Jun 23 13:50:47 2021 -0600
*
* Fix 'waitq' command for Linux 4.13 and later kernels
*
* The wait queue structs and members were renamed in 4.13 in commits:
*
* ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
* 9d9d676f595b ("sched/wait: Standardize internal naming of wait-queue
* heads")
* 2055da97389a ("sched/wait: Disambiguate wq_entry->task_list and
* wq_head->task_list naming")
*
* Add support to the 'waitq' command for these more recent kernels.
*
* [ kh: suppressed compilation warnings ]
*
* Signed-off-by: Greg Edwards <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit f091b5e76d2d6e81b12cd40df7b5863c9e2efed1
* Author: Firo Yang <email address hidden>
* Date: Tue May 25 18:17:37 2021 +0800
*
* list: add -O option for specifying head node offset
*
* The -O option is very useful to specify the embedded head node's
* offset which is different to the offset of other nodes embedded,
* e.g. dentry.d_subdirs (the head node) and dentry.d_child.
*
* [ kh: did some cosmetic adjustments ]
*
* Signed-off-by: Firo Yang <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit e61841a8b86ac551c314f74f4b82daae84f99700
* Author: Luc Chouinard <email address hidden>
* Date: Wed Jun 9 07:59:40 2021 -0400
*
* extensions/eppic.mk: Enable use of alternate eppic branch
*
* Made significant changes and fixes to eppic.
* Using options in the clone command break due to args parsing.
* Use separate variable for clone options.
*
* Closes: https://github.com/crash-utility/crash/pull/86
*
* commit c15a1e025e62134094ba0ac600263d75673d5a22
* Author: Youling Tang <email address hidden>
* Date: Fri Apr 23 15:42:11 2021 +0800
*
* MIPS64: three fixes for MIPS64 kernels
*
* Three fixes for MIPS64 kernels:
* (1) To support ramdumps, add the machine_type() check for MIPS64 in
* ramdump_to_elf().
* (2) To fix a stuck issue when invoking crash with "-d1" or larger
* debug value, add the machine_type() check to get the correct
* dump NOTE offsets.
* (3) Fix the reference file path to the definition of the pt_regs
* structure, to which mips64_regster refers.
*
* [ kh: merged three patches into one ]
*
* Signed-off-by: Youling Tang <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 859d1c0e8a6618634cbc1fe7ee2b082a6a3c99a1
* Author: Youling Tang <email address hidden>
* Date: Fri Apr 23 15:40:41 2021 +0800
*
* MIPS32/64: Add 'irq' command support
*
* Add support for the 'irq' series of commands in the MIPS32/64
* architecture, except for the 'irq -d' command, others can be
* used. Without the patch, the 'irq' command fails as follows:
*
* irq: cannot determine number of IRQs
*
* Signed-off-by: Youling Tang <email address hidden>
*
* commit 704623dfde43da98ffb354b3d7f450cd012a8215
* Author: Youling Tang <email address hidden>
* Date: Thu Jun 3 16:07:41 2021 +0800
*
* defs.h: Fix the value of TIF_SIGPENDING macro
*
* Correct the change of the value of TIF_SIGPENDING macro between
* different kernel versions.
*
* TIF_SIGPENDING changes with the kernel version as follows:
* ARM 2 -> 0 at v2.6.23
* MIPS 2 -> 1 at v2.6.23
* MIPS64 2 -> 1 at v2.6.23
* PPC 2 -> 1 at v2.6.23
* IA64 1 -> 0 at v2.6.23
* PPC64 2 -> 1 at v2.6.23
* S390 2 -> 1 at v3.16
* S390X 2 -> 1 at v3.16
*
* Signed-off-by: Youling Tang <email address hidden>
*
* commit ec44b902d3467e7b86ee39e2d7d472b9cb202148
* Author: Kazuhito Hagio <email address hidden>
* Date: Mon May 31 14:08:28 2021 +0900
*
* memory: Fix for "kmem -n" option to display NID correctly
*
* The nid member of struct memory_block is a 4-byte integer, but read
* and printed as a 8-byte integer on 64-bit machines. Without the
* patch, the option displays wrong NIDs.
*
* crash> kmem -n
* ...
* MEM_BLOCK ... NODE STATE START_SECTION_NO
* ffff9edeff2b9400 ... 14195095130662240256 ONLINE 0
* ffff9edeff2bb400 ... 14195094718345379840 ONLINE 32
*
* The issue seems to appear on Linux 5.12 and later kernels that contain
* commit e9a2e48e8704c ("drivers/base/memory: don't store phys_device
* in memory blocks"), which changed the arrangement of the members of
* struct memory_block.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 0b5435e10161345cf713ed447a155a611a1b408b
* Author: Kazuhito Hagio <email address hidden>
* Date: Wed May 26 17:33:13 2021 +0900
*
* memory: Add support for SECTION_TAINT_ZONE_DEVICE flag
*
* Fix for "kmem -n|-p" options on Linux 5.12-rc1 and later kernels
* that contain commit 1f90a3477df3f ("mm: teach pfn_to_online_page()
* about ZONE_DEVICE section collisions"). Without the patch, the
* "kmem -n" option incorrectly shows mem_map addresses containing the
* flag in bit 5 as part of the virtual address, and also the "kmem -p"
* option shows page structures at wrong position. With the patch,
* the "kmem -n" option displays the new "D" state flag.
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 647a5c33e1c94054d7b63168cd6c12901591cb77
* Author: Lianbo Jiang <email address hidden>
* Date: Thu May 27 18:02:11 2021 +0800
*
* Fix for "kmem -s|-S" option on Linux 5.7 and later kernels
*
* Linux 5.7 and later kernels that contain kernel commit 1ad53d9fa3f6
* ("slub: improve bit diffusion for freelist ptr obfuscation") changed
* the calculation formula in the freelist_ptr(), which added a swab()
* call to mix bits a little more. When kernel is configured with the
* "CONFIG_SLAB_FREELIST_HARDENED=y", without the patch, the "kmem -s|-S"
* options display wrong statistics and state whether slab objects are
* in use or free and can print the following errors:
*
* ...
*
* Signed-off-by: Lianbo Jiang <email address hidden>
*
* commit a7ecf2467f953b632713f38ab8104596755bca8c
* Author: John Donnelly <email address hidden>
* Date: Wed May 12 14:48:03 2021 -0700
*
* arm64: Add lowercase tcr_el1_t1sz
*
* Commit 1c45cea "arm64: Change tcr_el1_t1sz variable name to
* TCR_EL1_T1SZ", renamed the variable to upper case, but there are
* kernels in existence that still have the lower case name, which
* breaks crash backwards compatibility.
*
* Resolves: https://github.com/crash-utility/crash/pull/82
* Signed-off-by: John Donnelly <email address hidden>
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
* commit 1ee4c407d7874b8eef17e863671edc8ccfdd7c71
* Author: Kazuhito Hagio <email address hidden>
* Date: Tue May 18 10:18:10 2021 +0900
*
* Mark start of 7.3.1 development phase with version 7.3.0++
*
* Signed-off-by: Kazuhito Hagio <email address hidden>
*
-- Matthias Klose <email address hidden> Wed, 23 Mar 2022 15:07:01 +0100
