Kernel exception handling method and system

Abstract

This application relates to the field of kernel exception handling, and discloses a kernel exception handling method and system. The kernel exception handling system includes an electronic device, a network console, and a remote host; the electronic device is communicatively connected to the network console and the remote host, and the network console is communicatively connected to the remote host. In this application, when the operating system of the electronic device experiences a kernel crash, the electronic device sends the kernel crash context information to the remote host and starts the network console; after receiving the context information, the remote host interacts with the network console to obtain the corresponding crash log, and performs accurate analysis of the cause of the kernel crash. This eliminates the need for large-capacity storage of Vmcore files, saving the requirement for storing Vmcore files.

Description

Technical Field

[0001] This application relates to the field of kernel processing technology, and in particular to a kernel exception handling method and system. Background Technology

[0002] Currently, electronic devices, such as computers, are equipped with the Linux operating system, but other types of operating systems may also be installed. Taking Linux as an example, a kernel crash refers to a crash in the Linux operating system kernel, although other types of operating systems and kernels can also crash. A kernel crash, also known as a kernel exception, means that the kernel has encountered an unrecoverable error, such as an incorrect instruction memory access address or an error in the instruction content itself. When a kernel exception occurs, the system generally needs to be restarted to recover.

[0003] Currently, the analysis of the causes of kernel crashes usually involves analyzing the memory dump file Vmcore generated by the kernel's memory dump mechanism Kdump. However, this method has high memory requirements. Summary of the Invention

[0004] The purpose of this application is to provide a kernel exception handling method and system that switches to a network console in kernel mode when a kernel exception occurs. The network console interacts with a remote host to analyze the cause of the kernel crash. This eliminates the need for large-capacity storage of the Vmcore file, thus saving the requirement for storing the Vmcore file.

[0005] To solve the above-mentioned technical problems, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a kernel exception handling method applied to a kernel exception handling system, the system including an electronic device, a network console, and a remote host; the electronic device is communicatively connected to the network console and the remote host, and the network console is communicatively connected to the remote host; the method includes:

[0007] When the operating system of the electronic device experiences a kernel crash, the electronic device sends the kernel crash context information to the remote host, and the electronic device starts the network console;

[0008] After receiving the context information, the remote host generates a debugging command and sends the debugging command to the network console.

[0009] The network console receives the debugging command sent by the remote host, and sends the crash log corresponding to the kernel crash to the remote host according to the debugging command;

[0010] After receiving the crash log, the remote host analyzes the cause of the kernel crash.

[0011] In some embodiments, the method further includes:

[0012] The electronic device determines whether the current instruction anomaly is a user-mode instruction anomaly.

[0013] If the current instruction exception is not a user-mode instruction exception, the electronic device determines that the current instruction exception is a kernel-mode instruction exception.

[0014] Electronic devices call interrupt functions to disable interrupts that cause kernel-mode exceptions.

[0015] In some embodiments, the electronic device uses a polling mechanism to send the kernel crash context information to the remote host; the remote host uses the polling mechanism to receive the context information; and the network console uses the polling mechanism to receive debugging commands sent by the remote host.

[0016] In some embodiments, after the remote host sends the debugging command to the network console, the method further includes:

[0017] The electronic device retrieves the crash log in the kernel log buffer;

[0018] The electronic device uses a polling mechanism to send the crash log to the network console.

[0019] In some embodiments, after receiving the crash log, the remote host analyzes the cause of the kernel crash, including:

[0020] After receiving the crash log, the remote host uses an exception analysis program to call the crash tool to analyze the crash log and obtain the cause of the kernel crash.

[0021] In some embodiments, after receiving the crash log, the remote host uses an anomaly analysis program to call a crash tool to analyze the crash log and obtain the cause of the kernel crash, including:

[0022] The remote host obtains the first instruction content and corresponding address of the instruction that caused the exception based on the crash log;

[0023] The remote host uses an anomaly analysis program to call a crash tool to determine whether the instruction that caused the anomaly is a memory access instruction.

[0024] If the remote host determines that the abnormal instruction is a memory access instruction, then the remote host determines whether the memory access address corresponding to the abnormal instruction is abnormal.

[0025] If the memory address corresponding to the abnormal instruction is abnormal, the remote host determines that the data access is abnormal and tracks the cause of the data access abnormality.

[0026] In some embodiments, the method further includes:

[0027] If the remote host determines that the abnormal instruction is not a memory access instruction, the remote host obtains the second instruction content from the exception analysis program according to the address corresponding to the abnormal instruction.

[0028] The remote host determines whether the content of the second instruction is consistent with the content of the first instruction.

[0029] If there is a difference between the content of the first instruction and the content of the second instruction, the remote host determines that the memory of the instruction that caused the anomaly has been modified.

[0030] The remote host analyzes the reason why the memory of the instruction that caused the anomaly was modified.

[0031] In some embodiments, after the memory access address corresponding to the instruction that caused the exception is abnormal, or after the remote host determines that the memory of the instruction that caused the exception has been modified, the method further includes:

[0032] The remote host obtains memory data from the network console, wherein the memory data corresponds to the reason for the memory access address abnormality or the reason for the memory being modified.

[0033] Secondly, embodiments of this application also provide a kernel exception handling system, the system including an electronic device, a network console, and a remote host; the electronic device is communicatively connected to the network console and the remote host, and the network console is communicatively connected to the remote host, wherein:

[0034] The electronic device is configured to send the kernel crash context information to the remote host when the operating system of the electronic device crashes, and the electronic device starts the network console.

[0035] The remote host is configured to generate a debugging command after receiving the context information, and send the debugging command to the network console.

[0036] The network console is used to receive debugging commands sent by the remote host, and to send the crash log corresponding to the kernel crash to the remote host according to the debugging commands;

[0037] The remote host is also used to analyze the cause of the kernel crash after receiving the crash log.

[0038] In some embodiments, the electronic device is further configured to:

[0039] Determine whether the current instruction exception is a user-mode instruction exception;

[0040] If the current instruction exception is not a user-mode instruction exception, then the current instruction exception is determined to be a kernel-mode instruction exception.

[0041] Call the interrupt function to disable interrupts that cause kernel-mode exceptions.

[0042] The beneficial effects of this application's embodiments are as follows: Unlike the prior art, the kernel exception handling method and system provided in this application's embodiments include an electronic device, a network console, and a remote host. When the operating system of the electronic device experiences a kernel crash, the electronic device sends the kernel crash context information to the remote host and starts the network console. After receiving the context information, the remote host interacts with the network console to obtain the corresponding crash log, enabling precise analysis of the kernel crash cause. This eliminates the need for large-capacity storage of Vmcore files, saving on the requirement for storing Vmcore files. Attached Figure Description

[0043] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0044] Figure 1 This is a schematic diagram of the kernel exception handling system of this application;

[0045] Figure 2 This is a schematic diagram of the hardware structure of the controller in one embodiment of the electronic device of this application;

[0046] Figure 3 This is a flowchart illustrating an embodiment of the kernel exception handling method of this application;

[0047] Figure 4 This is a schematic diagram of an embodiment of the crash log of the kernel exception handling method of this application;

[0048] Figure 5 This is a schematic diagram of the interaction between the remote host and the network console in the kernel exception handling method of this application. Detailed Implementation

[0049] The present application will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the system diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than the module division in the system or the order in the flowchart. In addition, the terms "first," "second," etc., used herein do not limit the data or execution order, but only distinguish identical or similar items with essentially the same function and effect.

[0052] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0053] Furthermore, the technical features involved in the various embodiments of this application described below can be combined with each other as long as they do not conflict with each other.

[0054] Currently, electronic devices, such as computers, are equipped with the Linux operating system, but other types of operating systems may also be installed. Taking Linux as an example, a kernel crash refers to the crash of the Linux operating system kernel. Of course, other types of operating systems and kernels can also be involved, and this is not a limitation here. A kernel crash, also known as a kernel exception, means that the kernel has encountered an unrecoverable error, such as an incorrect instruction memory access address or an error in the instruction content itself.

[0055] When the Linux operating system of an electronic device experiences a kernel crash, the Linux kernel's memory dump mechanism, known as the Kdump mechanism, can be used to capture the memory data at the scene of the kernel crash. The Kdump mechanism requires a resident memory capture kernel. When the kernel encounters an exception, the Linux kernel patch kexec is used to start the capture kernel. The patch kexec can bypass hardware initialization processes such as BIOS, allowing the production kernel's memory data to be preserved and read by the capture kernel for dumping.

[0056] The production kernel refers to the kernel used by the Linux kernel system in its working state; the captured kernel refers to the kernel that the Linux kernel system switches to when the production kernel crashes, as determined by the Kdump mechanism. The patch kexec can directly boot from the currently running kernel to a new kernel.

[0057] In some implementations, existing kernel anomaly analysis methods primarily rely on the massive Vmcore file, a memory dump file generated by the kdump mechanism when the Linux kernel crashes. This file preserves kernel debugging information at the time of the crash, including stack information, instruction memory contents, register information, etc., which can be used to analyze the cause of the kernel crash. However, for embedded systems, due to cost, size, power consumption, or security reasons, there is no large-capacity file system to store Vmcore files, and the kdump mechanism or similar methods are difficult to use in embedded systems.

[0058] Furthermore, if the kdump mechanism is used, at least 64MB of memory space needs to be reserved for capturing the kernel. Moreover, this part of the memory cannot be used when the production kernel is working. Considering that capturing the kernel is only used when the kernel crashes, and kernel crash is a low-probability, occasional event, it is not worthwhile to reserve at least 64MB of system memory.

[0059] Therefore, embodiments of this application provide a kernel exception handling system, such as... Figure 1 As shown, the kernel exception handling system 100 includes an electronic device 101, a network console 102, and a remote host 103; the electronic device 101 is communicatively connected to the network console 102 and the remote host 103, and the network console 102 is communicatively connected to the remote host 103.

[0060] The electronic device 101 is used to send the kernel crash context information to the remote host 103 when the operating system of the electronic device 101 experiences a kernel crash, and the electronic device 101 starts the network console 102.

[0061] The remote host 103 is used to generate a debugging command after receiving the context information, and send the debugging command to the network console 102;

[0062] The network console 102 is used to receive debugging commands sent by the remote host 103, and to send the crash log corresponding to the kernel crash to the remote host 103 according to the debugging commands.

[0063] The remote host 103 is also used to analyze the cause of the kernel crash after receiving the crash log.

[0064] Among them, electronic device 101, network console 102 and remote host 103 can all be computers. Electronic device 101 is equipped with a Linux operating system. The kernel crash of the operating system refers to the kernel crash of the Linux operating system. Of course, it can also be other types of operating systems and kernels, which are not limited here.

[0065] In some embodiments, the electronic device 101 is further configured to:

[0066] Determine whether the current instruction exception is a user-mode instruction exception;

[0067] If the current instruction exception is not a user-mode instruction exception, then the current instruction exception is determined to be a kernel-mode instruction exception.

[0068] Call the interrupt function to disable interrupts that cause kernel-mode exceptions.

[0069] Electronic device 101 determines whether its operating system has crashed by judging whether the current instruction exception is a user-mode instruction exception or a kernel-mode instruction exception.

[0070] In some embodiments, such as Figure 2 As shown, Figure 2 This is a schematic diagram of the hardware structure of the controller 11 in one embodiment of the electronic device 101. The controller 11 of the electronic device 101 is used to execute the method steps executed by the electronic device 101 in the kernel exception handling method, such as sending the kernel crash context information to the remote host 103 when the operating system of the electronic device 101 experiences a kernel crash, and starting the network console 102, etc.

[0071] Furthermore, the controller 11 of the electronic device 101 includes:

[0072] One or more processors 111 and memory 112. Figure 2 The example uses a processor 111 and a memory 112.

[0073] Processor 111 and memory 112 can be connected via a bus or other means. Figure 2 Taking the example of a connection between China and Israel via a bus.

[0074] The memory 112, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the kernel exception handling method in the embodiments of this application. The processor 111 executes various functional applications and data processing of the controller 11 by running the non-volatile software programs, instructions, and modules stored in the memory 112, thereby implementing the kernel exception handling method of the above method embodiments.

[0075] The memory 112 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device 101. Furthermore, the memory 112 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 112 may optionally include memory remotely located relative to the processor 111, and these remote memories may be connected to the electronic device 101 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0076] The one or more modules are stored in the memory 112. When executed by the one or more processors 111, they perform the steps executed by the electronic device 101 in any of the above method embodiments, for example, performing the steps described below. Figure 3 The method steps performed by electronic device 101 in steps S301 to S304.

[0077] The above-described product can execute the kernel exception handling method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in this embodiment can be found in the kernel exception handling method provided in the embodiments of this application.

[0078] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 2 One of the processors 111 can cause the one or more processors to perform the steps performed by the electronic device 101 in any of the above method embodiments, for example, to perform the steps described below. Figure 3 The method steps performed by electronic device 101 in steps S301 to S304.

[0079] The above-described embodiment of the electronic device 101 is merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0080] Similar to electronic device 101, network console 102 and remote host 103 also include controllers (not shown). The controller of network console 102 (not shown) executes the method steps executed by network console 102 in the kernel exception handling method, and the controller of remote host 103 (not shown) executes the method steps executed by remote host 103 in the kernel exception handling method.

[0081] The kernel exception handling system 100 provided in this application embodiment, by setting up a remote host 103 and a network console 102, sends the crash log to the remote host 103 for kernel crash cause analysis when the Linux operating system of the electronic device 101 crashes. It does not require a large file system to store the Vmcore file, and can accurately obtain the memory data to be analyzed according to the needs of exception location, saving the need to store the Vmcore file.

[0082] Please see Figure 3 The above is a flowchart illustrating an embodiment of the kernel exception handling method applied in this application. The method can be executed by the kernel exception handling system 100 and includes steps S301-S304.

[0083] S301: When the operating system of the electronic device 101 experiences a kernel crash, the electronic device 101 sends the kernel crash context information to the remote host 103, and the electronic device 101 starts the network console 102.

[0084] The operating system of electronic device 101 can be a Linux operating system. A kernel crash means that the kernel has encountered an unrecoverable error, such as an instruction memory access error or an error in the instruction content itself. When the kernel crashes, the operating system usually needs to be restarted to recover. A kernel crash is also called a kernel exception.

[0085] Because a kernel crash in the operating system of electronic device 101 would disable interrupts, if the serial port is removed during the product finalization phase (not the development phase) and general network PAI data transmission is not possible, electronic device 101 can use polling to send data commands to or receive commands from the network interface in order to transmit commands. This enables interaction between electronic device 101 and remote host 103, and between electronic device 101 and network console 102. The Linux kernel's polling mechanism is Netpoll. Netpoll is a pure polling mechanism for receiving data packets provided by the device interface layer based on NAPI mode. It relies only on the network device driver and does not depend on the interrupt mechanism or protocol stack. Netpoll enables the sending and receiving of UDP packets. The polling mechanism provides a way to send packets outwards in the event of interrupt exceptions or protocol stack exceptions, thus informing remote host 103 of its status.

[0086] Therefore, when the operating system of electronic device 101 experiences a kernel crash, electronic device 101 uses a polling mechanism to send the kernel crash context information to the network interface. The remote host 103 receives the context information through the network interface, and the electronic device 101 that experienced the kernel crash starts the network console 102 connected to it.

[0087] The context information at the time of a kernel crash is an effective means of locating the kernel and its drivers. Therefore, sending the context information to the remote host 103 can be done over the network to facilitate the remote host 103 in locating the cause of the kernel crash. Simultaneously, the electronic device 101 starts the network console 102 connected to it, thereby switching to the kernel-mode network console 102 mechanism, so that the network console 102 and the remote host 103 can analyze and locate the anomaly.

[0088] In some embodiments, the electronic device 101 determines whether a kernel crash has occurred in the operating system by analyzing the current instruction; therefore, the method may further include:

[0089] The electronic device 101 determines whether the current instruction abnormality is a user-mode instruction abnormality;

[0090] If the current instruction exception is not a user-mode instruction exception, then the electronic device 101 determines that the current instruction exception is a kernel-mode instruction exception;

[0091] Electronic device 101 calls an interrupt function to disable interrupts that cause kernel-mode exceptions.

[0092] Specifically, the operating system of electronic device 101 will constantly detect whether the current instruction is abnormal. Instruction abnormalities include user-mode instruction abnormalities and kernel-mode instruction abnormalities. User mode and kernel mode are obtained by dividing the architecture of the Linux operating system with system 100 calls as the boundary. The user mode and kernel mode of the operating system actually correspond to the execution states of non-privileged instructions and privileged instructions in the CPU instruction set. The CPU divides different execution levels to execute instructions with corresponding privileges.

[0093] Therefore, if the operating system of electronic device 101 detects an abnormal current instruction, electronic device 101 first determines whether the abnormal current instruction is a user-mode instruction. If the abnormal current instruction is a user-mode instruction, it means that the abnormal current instruction will not cause the kernel to crash. At this time, electronic device 101 only needs to send the signal of the abnormal user-mode instruction to the kernel, and the kernel processes the abnormal user-mode instruction so that the current instruction can continue to run normally.

[0094] If the current instruction exception is not a user-mode instruction exception, electronic device 101 can determine that the current instruction exception is a kernel-mode instruction exception. In this case, the operating system of electronic device 101 experiences a kernel crash. Electronic device 101 calls an interrupt function to disable the interrupt that caused the kernel-mode exception. The interrupt function can be a panic function. In the Linux operating system, when a fault is detected that the system cannot continue to run, the panic function is called to terminate the current instruction and disable kernel interrupts. The kernel operating system cannot recover on its own and enters a crash state.

[0095] When electronic device 101 determines that the operating system has experienced a kernel crash, the kernel log buffer Logbuf in electronic device 101 prints the context information at the time of the crash (including registers, stack information, etc.). Then, electronic device 101 sends the kernel crash context information to the remote host 103 through the network interface, and electronic device 101 starts the network console 102. The context information can be obtained from the kernel log buffer Logbuf.

[0096] When the operating system kernel of electronic device 101 crashes, electronic device 101 interacts with remote host 103 through netpoll to send context information when the crash occurs. The memory occupied is less than that of the capture kernel used by kdump, which requires tens of megabytes of memory. In this application, only the network console 102 occupies a portion of the instruction memory, which is only a few kilobytes and can be almost ignored.

[0097] S302: After receiving the context information, the remote host 103 generates a debugging command and sends the debugging command to the network console 102.

[0098] The remote host 103 uses a polling mechanism to receive context information sent by the electronic device 101 through the network interface, generates a debugging command, and then uses the polling mechanism to send the debugging command to the network console 102.

[0099] S303: The network console 102 receives the debugging command sent by the remote host 103, and sends the crash log corresponding to the kernel crash to the remote host 103 according to the debugging command.

[0100] The network console 102 uses a polling mechanism to receive debugging commands from the network interface, parses the debugging commands, and then sends the crash log corresponding to the kernel crash to the remote host 103 according to the debugging commands.

[0101] In order to obtain the crash log corresponding to the kernel crash, after the remote host 103 sends the debugging command to the network console 102, the method may further include:

[0102] The electronic device 101 retrieves the crash log in the kernel log buffer;

[0103] The electronic device 101 uses a polling mechanism to send the crash log to the network console 102.

[0104] Specifically, when the kernel of electronic device 101 crashes, network console 102 is started. Electronic device 101 retrieves the crash log from the kernel log buffer Logbuf. Then, due to the kernel crash, interrupts are disabled. Therefore, electronic device 101 uses a polling mechanism to send the crash log to the network interface. Network console 102 receives the crash log sent by electronic device 101 through the network interface.

[0105] After obtaining the crash log from the network console 102, the crash log is sent to the remote host 103.

[0106] S304: After receiving the crash log, the remote host 103 analyzes the cause of the kernel crash.

[0107] Specifically, after receiving the crash log, the remote host 103 directly analyzes the cause of the kernel crash. It does not require the electronic device 101 to generate the Vmcore file by the kdump mechanism when the kernel crash occurs. In other words, it does not need the Vmcore file to analyze the cause of the kernel crash. By using the remote host 103 to analyze the cause of the kernel crash, the electronic device 101 does not need to store the large-capacity Vmcore data file at once, thus saving storage space.

[0108] In some implementations, step S304 may include:

[0109] After receiving the crash log, the remote host 103 uses an exception analysis program to call the crash tool to analyze the crash log and obtain the cause of the kernel crash.

[0110] Specifically, the remote host 103 is equipped with an exception analysis program called crash wrapper. This exception analysis program can receive memory data of the kernel crash and the symbol table file vmlinux during kernel compilation. It can call the crash tool to perform data analysis and thus analyze the cause of the kernel crash.

[0111] In some implementations, after receiving the crash log, the remote host 103 uses an anomaly analysis program to call a crash tool to analyze the crash log and obtain the cause of the kernel crash, which may include:

[0112] The remote host 103 obtains the first instruction content and corresponding address of the instruction that caused the exception based on the crash log;

[0113] The remote host 103 uses an anomaly analysis program to call a crash tool to determine whether the instruction that caused the anomaly is a memory access instruction.

[0114] If the remote host 103 determines that the abnormal instruction is a memory access instruction, then the remote host 103 determines whether the memory access address corresponding to the abnormal instruction is abnormal.

[0115] If the memory address corresponding to the abnormal instruction is abnormal, the remote host 103 determines that the data access is abnormal and tracks the cause of the data access abnormality.

[0116] Specifically, the remote host 103 is equipped with a crash wrapper program. After the remote host 103 obtains the crash log, it retrieves the first instruction content and corresponding address of the instruction that caused the exception based on the crash log. The crash log obtained by the remote host 103 is as follows: Figure 4As shown, the crash log can be analyzed to determine the content of the first instruction of the instruction that caused the exception and its corresponding address. The exception occurred at instruction 0xc010ea48.

[0117] Then, remote host 103 uses the crash wrapper, an anomaly analysis program, to call the crash tool for further analysis. The crash tool has several analysis commands when analyzing the cause of the kernel crash, such as... Figure 5 As shown, commands such as bt, dis, sym, log, etc. are used for analysis. Different analysis commands represent different analysis methods. The remote host 103 calls different commands in the crash tool to analyze different causes of the anomaly.

[0118] Taking the analysis of data access anomalies as an example, the remote host 103 uses commands in the crash tool to determine whether the abnormal instruction is a memory access instruction. If the remote host 103 determines that the abnormal instruction is a memory access instruction, it then determines whether the memory address corresponding to the abnormal instruction is abnormal. Specifically, it can determine whether the memory address corresponding to the abnormal instruction is abnormal by combining the register contents in the crash log. If the memory address corresponding to the abnormal instruction is abnormal, the remote host 103 determines that there is a data access anomaly. The remote host 103 obtains memory data from the network console 102, and this memory data corresponds to the cause of the memory access anomaly. Then, the remote host 103 traces the cause of the data access anomaly. Specifically, it can trace the cause of the data access anomaly based on the disassembly instructions in the symbol table file vmlinux, thereby obtaining the cause of the kernel crash. Correspondingly, if the memory address corresponding to the abnormal instruction is not abnormal, the remote host 103 determines other causes of kernel crashes.

[0119] Correspondingly, if the remote host 103 determines that the abnormal instruction is not a memory access instruction, then the remote host 103 obtains the second instruction content from the exception analysis program based on the address corresponding to the abnormal instruction; the remote host 103 determines whether the second instruction content and the first instruction content are consistent; if the first instruction content and the second instruction content differ, then the remote host 103 determines that the memory of the abnormal instruction has been modified; the remote host 103 obtains memory data from the network console 102, which corresponds to the reason for memory modification, and the remote host 103 analyzes the reason for the memory modification of the abnormal instruction, thereby analyzing the cause of the kernel crash. Further, the reason for memory modification may be physical memory failure or data access exceeding limits, leading to a kernel crash.

[0120] Furthermore, if the remote host 103 determines that the content of the second instruction is consistent with the content of the first instruction, then the remote host 103 determines that the memory of the instruction that caused the exception has not been modified, and the remote host 103 determines other reasons for the kernel crash.

[0121] When analyzing the cause of a kernel crash, the analysis method using Vmcore files can be referenced. The difference between this method and the method using Vmcore files is that the remote host 103 in this application does not need to store all the data in the large Vmcore file at once when analyzing the cause of a kernel crash. It only needs to obtain the corresponding memory data from the network console 102 when different analysis commands are executed, which can accurately locate the memory data and thus save storage space. The use of other analysis commands can refer to the method of analyzing the cause of a kernel crash using Vmcore files, which will not be elaborated here.

[0122] Furthermore, when analyzing the cause of the kernel crash, considering that interrupts cannot be used when a kernel exception occurs, the network console 102 interacts with the remote host 103 in a polling manner to send and receive data. Unlike the existing technology where the Linux kernel simply sends the kernel crash log once and then crashes or restarts the operating system, when the remote host 103 analyzes the cause of the kernel crash, it sends different analysis program commands to the network console 102. This command can be a command to read memory data or a command to read device hardware registers. Based on the analysis commands sent by the remote host 103, the network console 102 selectively sends the corresponding memory data or registers, etc., to accurately locate the exception and comprehensively analyze the cause of the kernel exception.

[0123] The kernel exception handling method in this application embodiment sets up a remote host 103 and a network console 102. When the Linux operating system of the electronic device 101 experiences a kernel crash, the crash log is sent to the remote host 103 for kernel crash cause analysis. This method does not require a large file system to store the Vmcore file and can accurately obtain the memory data to be analyzed according to the needs of exception location, saving the need to store the Vmcore file.

[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; under the concept of the present invention, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the present invention as described above, which are not provided in detail for the sake of brevity; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A kernel exception handling method, characterized in that, An application is made in a kernel exception handling system, the system comprising an electronic device, a network console, and a remote host; the electronic device is communicatively connected to the network console and the remote host, and the network console is communicatively connected to the remote host; the method includes: When the operating system of the electronic device experiences a kernel crash, the electronic device uses a polling mechanism to send the kernel crash context information to the remote host, and the electronic device starts the network console. After receiving the context information using a polling mechanism, the remote host generates a debugging command and sends the debugging command to the network console using the polling mechanism. The debugging command includes a command to read memory data or a command to read registers. The network console uses a polling mechanism to receive debugging commands sent by the remote host, and sends the crash log corresponding to the kernel crash to the remote host according to the debugging commands; After receiving the crash log, the remote host analyzes the cause of the kernel crash.

2. The method according to claim 1, characterized in that, The method further includes: The electronic device determines whether the current instruction anomaly is a user-mode instruction anomaly. If the current instruction exception is not a user-mode instruction exception, the electronic device determines that the current instruction exception is a kernel-mode instruction exception. Electronic devices call interrupt functions to disable interrupts that cause kernel-mode exceptions.

3. The method according to claim 1, characterized in that, After the remote host sends the debugging command to the network console, the method further includes: The electronic device retrieves the crash log in the kernel log buffer; The electronic device uses a polling mechanism to send the crash log to the network console.

4. The method according to claim 1, characterized in that, After receiving the crash log, the remote host analyzes the cause of the kernel crash, including: After receiving the crash log, the remote host uses an exception analysis program to call the crash tool to analyze the crash log and obtain the cause of the kernel crash.

5. The method according to claim 4, characterized in that, After receiving the crash log, the remote host uses an exception analysis program to call a crash tool to analyze the crash log and obtain the cause of the kernel crash, including: The remote host obtains the first instruction content and corresponding address of the instruction that caused the exception based on the crash log; The remote host uses an anomaly analysis program to call a crash tool to determine whether the instruction that caused the anomaly is a memory access instruction. If the remote host determines that the abnormal instruction is a memory access instruction, then the remote host determines whether the memory access address corresponding to the abnormal instruction is abnormal. If the memory address corresponding to the abnormal instruction is abnormal, the remote host determines that the data access is abnormal and tracks the cause of the data access abnormality.

6. The method according to claim 5, characterized in that, The method further includes: If the remote host determines that the abnormal instruction is not a memory access instruction, the remote host obtains the second instruction content from the exception analysis program according to the address corresponding to the abnormal instruction. The remote host determines whether the content of the second instruction is consistent with the content of the first instruction. If there is a difference between the content of the first instruction and the content of the second instruction, the remote host determines that the memory of the instruction that caused the anomaly has been modified. The remote host analyzes the reason why the memory of the instruction that caused the anomaly was modified.

7. The method according to claim 6, characterized in that, After the memory access address corresponding to the instruction that caused the exception is abnormal, or after the remote host determines that the memory of the instruction that caused the exception has been modified, the method further includes: The remote host obtains memory data from the network console, wherein the memory data corresponds to the reason for the memory access address abnormality or the reason for the memory being modified.

8. A kernel exception handling system, characterized in that, The system includes an electronic device, a network console, and a remote host; the electronic device is communicatively connected to the network console and the remote host, and the network console is communicatively connected to the remote host, wherein: The electronic device is configured to send the kernel crash context information to the remote host using a polling mechanism when the operating system of the electronic device crashes, and the electronic device starts the network console. The remote host is configured to generate debugging commands after receiving the context information using a polling mechanism, and send the debugging commands to the network console using a polling mechanism. The debugging commands include commands to read memory data or commands to read registers. The network console is used to receive debugging commands sent by the remote host using a polling mechanism, and to send the crash log corresponding to the kernel crash to the remote host according to the debugging commands. The remote host is also used to analyze the cause of the kernel crash after receiving the crash log.

9. The system according to claim 8, characterized in that, The electronic device is also used for: Determine whether the current instruction exception is a user-mode instruction exception; If the current instruction exception is not a user-mode instruction exception, then the current instruction exception is determined to be a kernel-mode instruction exception. Call the interrupt function to disable interrupts that cause kernel-mode exceptions.

Images