crash 实用程序本身在解码内核模块中从空指针取消引用生成的 kdump 时崩溃

Question

我正在尝试使用

crash

实用程序来解码 Linux kdump 文件。

我的设置由在

qemu-system-aarch64

上运行的 Linux 内核 6.5 组成。使用的rootfs是buildroot。我已编辑

/etc/init.d/rcS

来设置 crashkernel 并生成 kdump。

#hackish way of achieving things
# Check if /proc/vmcore exists
if [ -e "/proc/vmcore" ]; then
    echo "collecting core"
    # Get the current date and time
    TSTAMP=$(date +"%Y%m%d%H%M%S")

    # Define the filename for the kdump file
    FILENAME="kernel.${TSTAMP}.core.kdump"

    # Run makedumpfile to create the vmcore dump
    makedumpfile --message-level 4 -d 17,31 /proc/vmcore "${FILENAME}"
    reboot
else
    echo "loading crashkernel into memory"
    # /proc/vmcore does not exist, so we run kexec
    kexec -p /Image --append="console=ttyAMA0,115200n8 root=/dev/nfs rw nfsroot=10.105.226.234:/home/naveen/nfsroot/rootfs-buildroot-arm64/,nolock,vers=4,tcp ip=10.105.226.235"
fi

我使用以下代码开发了一个简单的内核模块，以因空指针取消引用而产生崩溃：

static int __init null_deref_module_init(void) {
    // Pointer to an integer, initialized to NULL
    int *null_pointer = NULL;
    printk(KERN_INFO "Null dereference module loaded\n");

    // Dereferencing the NULL pointer to trigger a crash
    printk(KERN_INFO "Triggering null pointer dereference...\n");
    *null_pointer = 1; // This line will cause a null pointer dereference

    return 0; // This will never be reached
}

正如预期的那样，一旦我加载此内核模块，qemu 来宾内核就会崩溃。我也有一个成功的 kdump。当我使用 kdump 实用程序对其进行解码时（尝试了多个版本，包括最新的 8.0.4），该实用程序本身崩溃了。崩溃的可能原因是什么？

$ sudo crash ~/.repos/src/arm64/linux/vmlinux kernel.20240330170747.core.kdump
crash 8.0.4
Copyright (C) 2002-2022  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2022  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
Copyright (C) 2015, 2021  VMware, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=aarch64-elf-linux".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...

please wait... (determining panic task)Segmentation fault

如果我将此模块构建为内置模块，我会收到正确的崩溃消息（当然没有 kdump），

[   63.406244] pc : null_deref_module_init+0x30/0x1000 [npdereference]
[   63.407287] lr : null_deref_module_init+0x24/0x1000 [npdereference]

我已经将其记录为维护者的问题，但我等不及了。尽管它不应该崩溃，但我认为我可以通过提供它所期望的东西（尚未找到什么）来使崩溃实用程序高兴。会不会和内核模块的符号有关？有人可以提供提示来完成它吗？

Answer 1

我已经将此作为维护人员的问题记录下来，但我等不及了。

是的，可以。使用 OSS 的本质是，您不能要求您遇到的任何问题都能快速（或根本）得到解决，您只能希望它们能够得到解决。

---

您的第一步应该是在（本机）GDB 下运行

crash

，并找出 哪里它崩溃了。

完成后，您应该尝试使用

crash

的tip-of-trunk版本重现崩溃，然后尝试自己调试问题。

一旦您了解有关故障的其他详细信息，问题所在可能会变得显而易见，或者您可以使用

git blame

找出发生崩溃的代码的编写者并联系该人。

会不会和内核模块的符号有关？

它可以是任何东西。