Download from: https://crash-utility.github.io/ or https://github.com/crash-utility/crash/releases The crash-8.0.0 newly contains GDB 10.2 as the embedded gdb module. The GitHub master branch serves as a development branch that will contain all patches that are queued for the next release: $ git clone git://github.com/crash-utility/crash.git Known Issue: - eppic.so extension module cannot be built with this release. Changelog: commit ec568e2ea515b66343d3488d5d4b9a625d55b7ae Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> Date: Wed Nov 24 13:32:49 2021 +0900 crash-7.3.0 -> crash-8.0.0 Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 6bc104059b124ecac5c8244f84aae6d7cfdfe97c Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> 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. Link: https://listman.redhat.com/archives/crash-utility/2021-September/msg00044.html Reported-by: Martin Moore <martin.moore@xxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit b0dd73d2368275e101688b2aca0bc297fd1ba300 Author: Aaron Tomlin <atomlin@xxxxxxxxxx> 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 <atomlin@xxxxxxxxxx> commit 64f48ee6719632895cd8a0922e84a4626e3790d8 Author: Aaron Tomlin <atomlin@xxxxxxxxxx> 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 <atomlin@xxxxxxxxxx> commit bfa596f40650e5a061b15d41b0a5b108610b11e9 Author: Aaron Tomlin <atomlin@xxxxxxxxxx> Date: Mon Nov 1 11:39:32 2021 +0000 kernel: consolidate show_kernel_taints() No functional change. Signed-off-by: Aaron Tomlin <atomlin@xxxxxxxxxx> commit 8246dce99dd23457e8c7a3fe9609c706694d1959 Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> 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 <er.ankurbansal@xxxxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 01d20ca1861ffaf449c1c60aa0536e9f42200ad3 Author: Philipp Rudo <prudo@xxxxxxxxxx> 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 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 <prudo@xxxxxxxxxx> commit 68870c83d299603c07785e3530e33c13045c87ef Author: Alexander Egorenkov <egorenar@xxxxxxxxxxxxx> 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 <egorenar@xxxxxxxxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit c180a63f2cb370da6097ad97eb07333c07aa988b Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> 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 <er.ankurbansal@xxxxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 5c04a6f3f923af7c50f0d853477044802b3fa6ec Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> commit df0049d12b2ced1b6ff7350ee3c0ca28c3f7cd52 Author: Tao Liu <ltao@xxxxxxxxxx> 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 <lijiang@xxxxxxxxxx> Suggested-by: Philipp Rudo <prudo@xxxxxxxxxx> Signed-off-by: Tao Liu <ltao@xxxxxxxxxx> commit 1e23335dab6bf9f6219a23bf0be4ad9f433f4f43 Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> Reviewed-by: Philipp Rudo <prudo@xxxxxxxxxx> commit f3bee9375ed32b85e7f81a5e46a0040620553ae0 Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> Reviewed-by: Philipp Rudo <prudo@xxxxxxxxxx> commit 340c6ad1a0a7ce76eb5d9397833bfc6a049e2b3b Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> commit 214f9bf3727c3350401b3f4b4389258c24486e06 Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> Reviewed-by: Philipp Rudo <prudo@xxxxxxxxxx> commit 2fab8fbc0c4f1c4cbe889de4cead5f7457a19f77 Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> commit f7e3b2d9b753793e230a5242974a111cdf139e49 Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> Date: Thu Sep 30 11:04:31 2021 +0900 .gitignore: add gdb-10.2 directory Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 05a3a328fcd8920e49926b6d1c9c81ce0b6acbca Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> 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 <k-hagio-ab@xxxxxxx> commit c1e256249426dd59ceea99038451a39e98a26790 Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> 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 <k-hagio-ab@xxxxxxx> commit 5c2d8d2d9da6423eec076fd51049d7b4677b61c6 Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> commit b8e1f2735b8dd1303aeb2affa309a2a409a82d38 Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> commit 51f21b0d1c91a4ae02ebf0d8c81460ec8b6c1283 Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> commit fce91bec5bef534e52f3261cc289a21a2cdb5fe3 Author: Tao Liu <ltao@xxxxxxxxxx> 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 <ltao@xxxxxxxxxx> Signed-off-by: Lianbo Jiang <lijiang@xxxxxxxxxx> commit 8d6f677e54a2474b3da19402e29278b62603d71d Author: Alexey Makhalov <amakhalov@xxxxxxxxxx> 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 <amakhalov@xxxxxxxxxx> Signed-off-by: Tao Liu <ltao@xxxxxxxxxx> commit 6c5f0c6ff5d158f2ef4fa997a052b0643d0c25ee Author: Alexey Makhalov <amakhalov@xxxxxxxxxx> 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 <amakhalov@xxxxxxxxxx> commit 96716862765f73676bfdb2d19fc5872364d21b73 Author: Alexey Makhalov <amakhalov@xxxxxxxxxx> 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 <amakhalov@xxxxxxxxxx> commit e832e0eb5bd8d97dfa9f4bd0e22fbfad849c11df Author: Alexey Makhalov <amakhalov@xxxxxxxxxx> 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 <amakhalov@xxxxxxxxxx> commit 2f967fb5ebd737ce5eadba462df35935122e8865 Author: Alexey Makhalov <amakhalov@xxxxxxxxxx> 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 <amakhalov@xxxxxxxxxx> commit 0b85218983ffcf939a638f1133871079c5615a46 Author: Alexey Makhalov <amakhalov@xxxxxxxxxx> 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 <amakhalov@xxxxxxxxxx> Reported-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 36e9d8673e9205f4ea4daad61c199597920c93df Author: Alexey Makhalov <amakhalov@xxxxxxxxxx> 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 <amakhalov@xxxxxxxxxx> Reported-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 163abcbbabdf8207c11ee93b1c909d85ecbcbf1f Author: Alexey Makhalov <amakhalov@xxxxxxxxxx> 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 <amakhalov@xxxxxxxxxx> commit 9fab193edb34ddf30282b5ac137f7d8078198938 Author: Alexey Makhalov <amakhalov@xxxxxxxxxx> 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 <amakhalov@xxxxxxxxxx> Signed-off-by: Lianbo Jiang <lijiang@xxxxxxxxxx> commit 7f38d1baf794823355ee100b3a1914155d4190f2 Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> 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 <k-hagio-ab@xxxxxxx> commit cf0c8d10e1870d89b39f40382634db51aa8fcf2c Author: Hari Bathini <hbathini@xxxxxxxxxxxxx> 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 extentions while searching for the object file under /usr/lib/debug/lib/modules directory. Signed-off-by: Naveen N. Rao <naveen.n.rao@xxxxxxxxxxxxx> Signed-off-by: Hari Bathini <hbathini@xxxxxxxxxxxxx> commit 15765867c0f1d937db5ec06f51adb6bfd13354ea Author: Ritesh Harjani <riteshh@xxxxxxxxxxxxx> 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 <riteshh@xxxxxxxxxxxxx> commit 3db5fff2e9d7b8762d1bd46d8d2c47ba4c7e374f Author: Ritesh Harjani <riteshh@xxxxxxxxxxxxx> 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 <riteshh@xxxxxxxxxxxxx> commit 4b34197508578bb43639e6d169fb91fb0489fa2b Author: James Hsu <james.hsu@xxxxxxxxxxxx> 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 <james.hsu@xxxxxxxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 44e5801d9016987b6b4ebd571bfde8ae3e75da7b Author: Philipp Rudo <prudo@xxxxxxxxxx> 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 <prudo@xxxxxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 881f33d97cee9895796829d0cc969b51dd34d831 Author: Roman Bolshakov <r.bolshakov@xxxxxxxxx> 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 <r.bolshakov@xxxxxxxxx> commit 1425b0504b1e79d88a2d188d7e4c0e7fceba4501 Author: Roman Bolshakov <r.bolshakov@xxxxxxxxx> 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 <r.bolshakov@xxxxxxxxx> commit 41cda195c6421fbde72ed67b32b8c1ab3eb0c56f Author: Roman Bolshakov <r.bolshakov@xxxxxxxxx> 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 <r.bolshakov@xxxxxxxxx> commit 4631320e96f8a63c897fbbce4e87e3c47af40bc9 Author: Roman Bolshakov <r.bolshakov@xxxxxxxxx> 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 <r.bolshakov@xxxxxxxxx> commit 80334ed25820cc08d147de5da361f427885cdd9e Author: Aaron Tomlin <atomlin@xxxxxxxxxx> 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 <atomlin@xxxxxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit f53b73e8380bca054cebd2b61ff118c46609429b Author: Pingfan Liu <piliu@xxxxxxxxxx> 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 <piliu@xxxxxxxxxx> commit bf1379a8b6ff8d6a8fa12978f7194f15f85c4380 Author: Pingfan Liu <piliu@xxxxxxxxxx> 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 <piliu@xxxxxxxxxx> commit 167d37e347fe35c6f7db826e8539e192c4375564 Author: Pingfan Liu <piliu@xxxxxxxxxx> 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 <piliu@xxxxxxxxxx> commit 5719afc7a40868418405a87a2711088556e68a3b Author: Pingfan Liu <piliu@xxxxxxxxxx> 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 <piliu@xxxxxxxxxx> commit d6b4f36d6b22b70fb14e692f36d20910ef5563c1 Author: Alexander Egorenkov <egorenar@xxxxxxxxxxxxx> 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 <egorenar@xxxxxxxxxxxxx> commit 4badc6229c69f5cd9da7eb7bdf400a53ec6db01a Author: Petr Tesařík <ptesarik@xxxxxxx> 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 <ptesarik@xxxxxxxx> commit eaf14f852ae79f7745934e213661f1c6abac711e Author: Greg Edwards <gedwards@xxxxxxx> 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 <gedwards@xxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit f091b5e76d2d6e81b12cd40df7b5863c9e2efed1 Author: Firo Yang <firo.yang@xxxxxxxx> 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 <firo.yang@xxxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit e61841a8b86ac551c314f74f4b82daae84f99700 Author: Luc Chouinard <lucchouina@xxxxxxxxx> 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 <tangyouling@xxxxxxxxxxx> 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 <tangyouling@xxxxxxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 859d1c0e8a6618634cbc1fe7ee2b082a6a3c99a1 Author: Youling Tang <tangyouling@xxxxxxxxxxx> 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 <tangyouling@xxxxxxxxxxx> commit 704623dfde43da98ffb354b3d7f450cd012a8215 Author: Youling Tang <tangyouling@xxxxxxxxxxx> 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 <tangyouling@xxxxxxxxxxx> commit ec44b902d3467e7b86ee39e2d7d472b9cb202148 Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> 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 NAME PHYSICAL RANGE NODE STATE START_SECTION_NO ffff9edeff2b9400 memory0 0 - 7fffffff 14195095130662240256 ONLINE 0 ffff9edeff2bb400 memory2 100000000 - 17fffffff 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 <k-hagio-ab@xxxxxxx> commit 0b5435e10161345cf713ed447a155a611a1b408b Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> 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. Without the patch: crash> kmem -n ... NR SECTION CODED_MEM_MAP MEM_MAP STATE PFN 1040 ffff9edf3ffd4100 ffffe2bcc0000010 ffffe2bd42000010 PMOE 34078720 ^ ^ crash> kmem -p PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffffe2bd42000010 2080000000 400040 1ffffffff 9961471 dead000000000122 referenced,active,error ffffe2bd42000050 2080001000 800080 1ffffffff 9961471 dead000000000122 referenced,active,error ffffe2bd42000090 2080002000 0 1ffffffff 9961471 dead000000000122 referenced,active,error ^^ With the patch: crash> kmem -n ... NR SECTION CODED_MEM_MAP MEM_MAP STATE PFN 1040 ffff9edf3ffd4100 ffffe2bcc0000000 ffffe2bd42000000 PMOED 34078720 crash> kmem -p PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffffe2bd42000000 2080000000 ffff9ebfc0044100 0 1 97ffffc0000200 slab ffffe2bd42000040 2080001000 ffff9ebfc0044400 0 1 97ffffc0000200 slab ffffe2bd42000080 2080002000 0 0 1 97ffffc0000000 Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 647a5c33e1c94054d7b63168cd6c12901591cb77 Author: Lianbo Jiang <lijiang@xxxxxxxxxx> 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: crash> kmem -s CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME 87201e00 528 0 0 0 8k xfs_dqtrx 87201f00 496 0 0 0 8k xfs_dquot kmem: xfs_buf: slab: 37202e6e900 invalid freepointer: b844bab900001d70 kmem: xfs_buf: slab: 3720250fd80 invalid freepointer: b8603f9400001370 ... Signed-off-by: Lianbo Jiang <lijiang@xxxxxxxxxx> commit a7ecf2467f953b632713f38ab8104596755bca8c Author: John Donnelly <john.p.donnelly@xxxxxxxxxx> 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 <john.p.donnelly@xxxxxxxxxx> Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> commit 1ee4c407d7874b8eef17e863671edc8ccfdd7c71 Author: Kazuhito Hagio <k-hagio-ab@xxxxxxx> 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 <k-hagio-ab@xxxxxxx> -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility