Fault handling method and apparatus

Abstract

Embodiments of the present specification provide a fault processing method and device, wherein the fault processing method comprises: in response to a fault event of a kernel module, determining a function call path corresponding to the kernel module; in the case that it is determined according to the function call path that the fault event belongs to a kernel scheduling function, determining a repair function in the function call path based on a target processor running in the kernel module, determining a historical state parameter of the target processor calling the repair function, and determining the historical state parameter as a current state parameter of the target processor; and scheduling a to-be-processed task to the target processor through the kernel module, wherein the target processor calls and executes the repair function based on the current state parameter to process the to-be-processed task.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to a fault handling method. Background Technology

[0002] As customer demands continue to increase, server performance needs to be continuously improved, leading to upgrades in server hardware configurations, such as CPUs reaching over a thousand cores and memory exceeding terabytes. This increase in server hardware also raises the failure rate; operating systems are becoming increasingly complex, and with the addition of hardware, the number of drivers also increases, introducing more and more potential faults.

[0003] The scheduler, as an important module of the server operating system kernel, often experiences crashes. Kernel failures can lead to the interruption of upper-layer services, which in turn can cause the entire operating system to restart, reducing the operating system's service life. Therefore, there is an urgent need for an effective method to solve this problem. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a fault handling method. One or more embodiments of this specification also relate to a fault handling apparatus, a computing device, a computer-readable storage medium, and a computer program, to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a fault handling method is provided, comprising:

[0006] In response to a fault event in a kernel module, determine the function call path corresponding to that kernel module;

[0007] If the fault event is determined to belong to a kernel scheduling function based on the function call path, then the repair function in the function call path is determined based on the target processor running the kernel module.

[0008] Determine the historical state parameters of the target processor calling the repair function, and set the historical state parameters as the current state parameters of the target processor;

[0009] The kernel module schedules the pending task to the target processor, wherein the target processor calls and executes the repair function based on the current state parameters to process the pending task.

[0010] Optionally, determining the function call path corresponding to the kernel module includes:

[0011] The stack region of the kernel module is backtracked to obtain the function call path corresponding to the kernel module.

[0012] Optionally, determining the repair function in the function call path based on the target processor running the kernel module includes:

[0013] Based on the target processor running on the kernel module, trace back at least one upper-level function of the kernel scheduling function in the function call path;

[0014] The repair function for the target processor is determined based on the at least one upper-level function, wherein the target processor is any one of the processors running in the kernel module, and the target processor has a history of calling the repair function.

[0015] Optionally, scheduling the task to be processed to the target processor through the kernel module includes:

[0016] Determine the fault run queue corresponding to the event node of the fault event for the target processor;

[0017] Based on the identifier of the target processor, determine the tasks to be processed in the global task list that are associated with the target processor;

[0018] The fault run queue is cleared, and the tasks to be processed are scheduled to the fault run queue according to the task processing order of the tasks to be processed, and the kernel module is used to construct the target run queue of the target processor.

[0019] Optionally, before determining the repair function in the function call path based on the target processor running the kernel module, the method further includes:

[0020] Determine whether the target processor acquires the corresponding spinlock at the event node of the fault event;

[0021] If so, then the process based on the target processor running the kernel module is executed to determine whether there is a repair function to be restored in the function call path.

[0022] Optionally, the fault handling method further includes:

[0023] If the target processor fails to acquire the corresponding spinlock at the event node of the fault event, the target processor detects whether the spinlock has been released, and acquires the spinlock if the spinlock is detected to have been released.

[0024] Optionally, determining the repair function for the target processor based on the at least one upper-level function includes:

[0025] Determine whether the at least one upper-level function contains a history call function of the target type;

[0026] If so, the historical call function will be used as the repair function for the target processor.

[0027] Optionally, the fault handling method further includes:

[0028] The stack area of ​​the kernel module is backtracked, and the backtracking results are parsed to generate the historical calls to the repair function and / or the context data generated during the execution process.

[0029] The context data is used as the historical state parameter of the repair function.

[0030] Optionally, scheduling the task to be processed to the target processor through the kernel module includes:

[0031] Determine the fault run queue corresponding to the event node of the fault event for the target processor;

[0032] Clear the fault run queue, and scan and determine whether the i-th task in the global task list is a task associated with the target processor according to the order of the tasks to be processed in the global task list. Here, i is a positive integer less than or equal to n, and i starts from 1. n is the number of tasks to be processed in the global task list.

[0033] If so, the task to be processed is scheduled to the fault run queue through the kernel module;

[0034] i increments by 1;

[0035] Determine if i is greater than n;

[0036] If not, then continue to execute the process of scheduling the pending task to the fault run queue through the kernel module;

[0037] If so, the fault run queue generated by the scheduling will be used as the target run queue of the target processor.

[0038] According to a second aspect of the embodiments of this specification, a fault handling apparatus is provided, comprising:

[0039] The first determining module is configured to determine the function call path corresponding to the kernel module in response to a fault event of the kernel module;

[0040] The second determining module is configured to, when determining that the fault event belongs to a kernel scheduling function based on the function call path, determine the repair function in the function call path based on the target processor running the kernel module;

[0041] The processing module is configured to determine the historical state parameters of the target processor calling the repair function, and to determine the historical state parameters as the current state parameters of the target processor;

[0042] The scheduling module is configured to schedule the pending task to the target processor through the kernel module, wherein the target processor calls and executes the repair function based on the current state parameters to process the pending task.

[0043] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising:

[0044] Memory and processor;

[0045] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions:

[0046] In response to a fault event in a kernel module, determine the function call path corresponding to that kernel module;

[0047] If the fault event is determined to belong to a kernel scheduling function based on the function call path, the repair function in the function call path is determined based on the target processor running the kernel module.

[0048] Determine the historical state parameters of the target processor calling the repair function, and set the historical state parameters as the current state parameters of the target processor;

[0049] The kernel module schedules the pending task to the target processor, wherein the target processor calls and executes the repair function based on the current state parameters to process the pending task.

[0050] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of any of the fault handling methods described herein.

[0051] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described fault handling method.

[0052] In one embodiment of this specification, in response to a fault event of a kernel module, the function call path corresponding to the kernel module is determined. If the fault event is determined to belong to a kernel scheduling function based on the function call path, a repair function in the function call path is determined based on the target processor running the kernel module. The historical state parameters of the target processor calling the repair function are determined and set as the current state parameters of the target processor. The kernel module schedules the task to be processed to the target processor, wherein the target processor calls and executes the repair function based on the current state parameters to process the task to be processed.

[0053] In this embodiment of the specification, when a kernel module malfunctions, specifically when the kernel scheduler (i.e., the scheduling function) is identified as faulty, a repair function for the target processor running on the kernel module is determined based on the kernel module's function call path. The current state of the target processor is then repaired based on its historical state parameters from calling this repair function. The repaired target processor then re-calls and executes the repair function, thereby achieving fault repair. This helps avoid the interruption of upper-layer service operation and subsequent operating system restart due to kernel scheduler failure. Therefore, the fault handling method provided in this embodiment can promptly repair faults, reducing the overall downtime rate of the operating system and ensuring uninterrupted operation, thus improving operational efficiency. Attached Figure Description

[0054] Figure 1 This is a flowchart illustrating a fault handling method provided in one embodiment of this specification;

[0055] Figure 2 This is a flowchart illustrating the process of a fault handling method provided in one embodiment of this specification.

[0056] Figure 3 This is a schematic diagram of the structure of a fault handling device provided in one embodiment of this specification;

[0057] Figure 4 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0058] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0059] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0060] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0061] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0062] Kernel: The core internal program of an operating system.

[0063] Scheduler: The program that manages and decides which processes run in the kernel.

[0064] Stack: A hierarchical structure formed during code execution that records the call path of the currently running code.

[0065] Stack backtracking: A backtracking method that uses a stack structure to obtain the call path of the currently running code.

[0066] Interrupt: A signal sent by a hardware device to the CPU that can interrupt the CPU's operation. The CPU can be configured to decide whether or not to be interrupted.

[0067] Spin lock: A type of synchronization lock where the code that acquires the lock does not relinquish the CPU but continuously occupies the CPU to run a loop attempting to acquire the lock, while interrupt handling is disabled.

[0068] Run queue: The structure used by the scheduler to manage running processes. Each CPU maintains a run queue, and each run queue is protected by a spinlock. To operate on a process in the run queue, you need to acquire the corresponding spinlock. The spinlock protects the atomicity of operating on the run queue.

[0069] As an important module of the kernel, the scheduler is prone to crashes. Kernel failures can lead to the interruption of upper-layer services, which in turn can cause the entire operating system to restart, reducing the operating system's service availability.

[0070] Based on this, the embodiments of this specification propose a fault recovery method that automatically restores the operation of the scheduler when a fault occurs, thereby avoiding the entire system from crashing and restarting. It also helps to improve the service life of the operating system and improve the operating efficiency of the operating system.

[0071] This specification provides a fault handling method, and also relates to a fault handling apparatus, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0072] Figure 1 A flowchart of a fault handling method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0073] Step 102: In response to a fault event in the kernel module, determine the function call path corresponding to the kernel module.

[0074] The fault handling methods provided in the embodiments of this specification are applied to operating systems.

[0075] Specifically, an operating system includes a kernel module, which is the most basic part of the operating system. It is used to manage computer programs that issue data I / O requests from software, and translate these requests into data processing instructions for processing by the processor (CPU) and other electronic components.

[0076] The kernel module can run multiple processors, i.e., multiple CPUs. Each CPU maintains a run queue, and each run queue may contain multiple tasks to be processed. The CPU can process these tasks by running program code. For the program code to run correctly, processes need to be created for it. When a process ends or is interrupted, process scheduling is required. This can be implemented by a process scheduler (kernel scheduler). The process scheduler needs to select the next process during the scheduling process and then perform a context switch.

[0077] However, in practical applications, before a kernel module malfunctions (kernel scheduler failure) and enters an interrupt, process scheduling is disabled, preventing the kernel module from scheduling other processes to execute, which in turn leads to an operating system restart. To avoid an operating system restart, a fault handling function can be entered in the event of a kernel module failure to perform fault recovery.

[0078] Specifically, the kernel scheduler can select and schedule processes through scheduling functions. Therefore, a scheduler failure is equivalent to a failure of the scheduling function. In the event of a scheduling function failure, the execution of the scheduling function can be switched to calling and executing a fault handling function, so as to perform fault recovery based on the fault handling function.

[0079] Furthermore, the embodiments in this specification can set different fault handling functions for different types of faults. Different fault handling functions can be used to characterize the handling methods for different types of faults. When a certain type of fault occurs, the corresponding fault handling function can be called and executed to handle and recover from that type of fault. Specifically, the corresponding fault handling functions for each type of fault can be set according to actual needs, and no restrictions are imposed here.

[0080] Furthermore, if a kernel module is found to be faulty, the function call path corresponding to that kernel module can be determined. This function call path can be used to determine whether the fault is caused by the scheduler, and based on the determination result, it can be determined whether to perform fault recovery.

[0081] In practice, the function call path corresponding to the kernel module is determined. Specifically, the stack area of ​​the kernel module can be backtracked to obtain the function call path corresponding to the kernel module.

[0082] The stack area in the embodiments of this specification is a hierarchical structure formed during program code execution. It can record snapshot information of the currently running program code, such as context data involved in the program code execution process. The context data may include the function call path corresponding to the kernel module and the register address during function execution.

[0083] Therefore, if a fault is found in a kernel module, the function call path corresponding to the kernel module can be determined by backtracking the stack area of ​​the kernel module.

[0084] In stack backtracking based on the fp register, the backtracking process follows the APCS (ARM Procedure Call Standard) specification. The fp register can locate the lr register data stored in the stack region; this data represents the function return address. Simultaneously, it can also locate the fp register data of the parent function, which points to the bottom of the parent function's stack. Thus, the lr and fp register data stored in the parent function's stack can be found using the same method to determine the parent function called and its stack bottom address. This constitutes a stack backtracking process. Through stack backtracking, the function call path corresponding to the kernel module can be determined, i.e., the call path between the function and its parent function. This function call path can be used to represent both historically called functions and the call relationships (call paths) between historically called functions.

[0085] By determining the function call path through stack backtracking, and based on this function call path, determining the repair function and the historical state parameters of the target processor during the historical calls to the repair function, the current system state of the target processor is restored based on the historical state parameters. The restored target processor is then used to reprocess the unprocessed tasks to achieve fault repair. This helps reduce the overall downtime rate of the operating system, thereby ensuring uninterrupted operation of the entire operating system and improving task processing efficiency.

[0086] Step 104: If the fault event is determined to belong to a kernel scheduling function based on the function call path, then the repair function in the function call path is determined based on the target processor running the kernel module.

[0087] Specifically, a repair function is a function that can be used for fault recovery.

[0088] After determining the function call path corresponding to the kernel module, the function call path can be parsed. Then, based on the parsing results, it can be determined whether the function causing the kernel module failure is a kernel scheduling function, that is, whether the failure is caused by the kernel scheduler. If so, the failure can be repaired; if not, the failure will not be repaired, and the default crash procedure will be entered.

[0089] In practical applications, when a kernel module fails, the run queue maintained by the processor running on the kernel module becomes a fault run queue. The execution order or number of tasks in this fault run queue may change due to the kernel module failure. Therefore, fault recovery requires repairing the fault run queue of the target processor and identifying a repair function from the functions called in the target processor's history. This repair function is then called and executed again to continue processing the tasks in the target processor's run queue.

[0090] Since the kernel module can run multiple processors, that is, multiple CPUs, and the target processor is any one of the multiple processors, and the target processor has a history of calling the repair function.

[0091] In specific implementation, based on the target processor running the kernel module, the repair functions in the function call path are determined, including:

[0092] Based on the target processor running on the kernel module, trace back at least one upper-level function of the kernel scheduling function in the function call path;

[0093] The repair function for the target processor is determined based on the at least one upper-level function, wherein the target processor is any one of the processors running in the kernel module, and the target processor has a history of calling the repair function.

[0094] Furthermore, determining the repair function for the target processor based on the at least one upper-level function includes:

[0095] Determine whether the at least one upper-level function contains a history call function of the target type;

[0096] If so, the historical call function will be used as the repair function for the target processor.

[0097] Specifically, since different CPUs are used to process different tasks, meaning that different CPUs have different task queues, each CPU needs to call different functions to process the tasks in its task queue. This specification uses a target CPU from among multiple CPUs as an example. The function call path can determine the target CPU's historical function calls, i.e., which functions the target CPU called before the fault occurred, and these functions may contain repair functions.

[0098] In addition, if it is determined that the kernel module failure is caused by the kernel scheduling function, the function call path of the target CPU can be traced back based on the kernel scheduling function to determine at least one upper-level function of the kernel scheduling function contained in the function call path, and a repair function can be determined in at least one upper-level function, wherein there is a call relationship between the kernel scheduling function and at least one upper-level function.

[0099] For example, if the target CPU, while processing task 1, sequentially calls functions A, B, and C, where there is a call relationship between functions A and B (function A calls function B), and a call relationship between functions B and C (function B calls function C), and function C is a kernel scheduling function, with the function call path being: function A—function B—function C, and if function C is determined to be faulty, then functions A and B are the upper-level functions of function C. Therefore, it can be determined whether functions A and B are repair functions. If both functions A and B are repair functions, either one can be identified as the repair function. Alternatively, the repair function of the target CPU can be determined based on the hierarchical relationship between functions A, B, and C. For example, if function B is one level above function C, and function A is two levels above function C, then function B, with the closer hierarchical relationship, can be considered the repair function of the target CPU. Or, if either function A or B is a repair function, then that repair function can be identified as the repair function of the target CPU.

[0100] In practical applications, repair functions can be pre-set. This means that one, two, or more target types of functions can be pre-set as repair functions. In the event of a fault, the existence of a function of that type in the historical function calls of the target CPU can be determined directly based on the function call path. If it exists, any one of the functions of that type can be used as the repair function for the target CPU, or the nth function of that type called before the kernel scheduling function can be determined as the repair function for the target CPU. Here, n is a positive integer, and the value of n or the method of selecting the repair function can be determined according to actual needs, without any restrictions here.

[0101] By identifying a repair function and re-calling and executing that function to fix the fault, the overall downtime rate of the operating system can be reduced, thus ensuring uninterrupted operation of the entire operating system and improving task processing efficiency.

[0102] In specific implementation, before determining the repair function in the function call path based on the target processor running the kernel module, the following steps are also included:

[0103] Determine whether the target processor acquires the corresponding spinlock at the event node of the fault event;

[0104] If so, then based on the target processor running the kernel module, determine whether there is a repair function to be restored in the function call path.

[0105] Furthermore, if the target processor fails to acquire the corresponding spinlock at the event node of the fault event, the target processor detects whether the spinlock has been released, and acquires the spinlock if the spinlock is detected to have been released.

[0106] Specifically, the event node of a fault event is the time node when the fault occurs.

[0107] Spinlocks are a type of lock introduced to prevent multiprocessor concurrency and are widely used in kernel components such as interrupt handling. A spinlock is a locking mechanism proposed to protect shared resources. At any given time, a spinlock can have at most one holder; that is, only one execution unit can acquire the lock at any given time. Spinlocks do not cause the caller to sleep. If the spinlock is already held by another execution unit, the caller will continuously check whether the holder of the spinlock has released it.

[0108] Therefore, before determining the repair function in the function call path based on the target processor running in the kernel module, it is necessary to determine whether the target processor acquired the corresponding spinlock when the fault occurred. If the spinlock is acquired, it can be determined whether there is a repair function associated with the target processor in the function call path; if the spinlock is not acquired, the fault will not be repaired and the default crash procedure will be entered.

[0109] Step 106: Determine the historical state parameters of the target processor calling the repair function, and determine the historical state parameters as the current state parameters of the target processor.

[0110] Specifically, historical state parameters are the system state parameters of the target processor when the repair function is called.

[0111] In the event of a fault, if a repair function is required for fault recovery, the historical state parameters of the target processor can be determined, and the current state of the target processor can be repaired using these historical state parameters. That is, the historical state parameters of the target processor when the repair function was called are determined as the current state parameters of the target processor. The repaired target processor can then call and execute the repair function to process the tasks to be processed, thereby achieving fault recovery.

[0112] In practice, the stack area of ​​the kernel module can be backtracked, and the backtracking results can be parsed to generate the historical calls to the repair function and / or the context data generated during the execution process.

[0113] The context data is used as the historical state parameter of the repair function.

[0114] Specifically, kernel space and user space are the foundation of an operating system. Kernel functional modules run in kernel space (kernel mode) and can perform all operations, while applications run in user space (user mode). Kernel mode and user mode each have their own corresponding memory mappings, i.e., address spaces.

[0115] If a user-space application needs to request system services, such as operating a physical device or mapping a segment of device space addresses to user space, it must do so through system calls (interface functions provided by the operating system to user space).

[0116] Through a system call, a user-space application enters kernel space, where the kernel runs the application's process on its behalf. Because user space and kernel space have different address mappings and general-purpose or dedicated register sets, and because the user-space process needs to pass many variables and parameters to the kernel, and the kernel also needs to save some registers and variables of the user process so that it can return to user space to continue execution after the system call ends, this process involves context switching.

[0117] The process context refers to the values ​​in the CPU registers, the process state, and the contents of the stack during process execution. When the kernel needs to switch to another process, it needs to save the current process's state parameters, that is, save the current process's process context, so that when the process is executed again, the system state at the time of the switch can be restored and execution can continue.

[0118] Therefore, for the historical state parameters of the target processor calling the repair function, the kernel module's stack area can be backtracked, the backtracking results can be parsed, and the historical call and / or execution context data of the repair function can be generated. The context data can then be used as the historical state parameters of the repair function to repair the current state of the target processor.

[0119] Step 108: The kernel module schedules the task to be processed to the target processor, wherein the target processor calls and executes the repair function based on the current status parameters to process the task to be processed.

[0120] In practice, the kernel module schedules the tasks to be processed to the target processor, which can be achieved in the following ways:

[0121] Determine the fault run queue corresponding to the event node of the fault event for the target processor;

[0122] Based on the identifier of the target processor, determine the tasks to be processed in the global task list that are associated with the target processor;

[0123] The fault run queue is cleared, and the tasks to be processed are scheduled to the fault run queue according to the task processing order of the tasks to be processed, and the kernel module is used to construct the target run queue of the target processor.

[0124] Specifically, since multiple processors run in the kernel module, the global task list contains pending tasks that each processor needs to process.

[0125] When a fault is determined in the kernel module, the processor's run queue at the time of the fault can be identified as the fault run queue. That is, due to the fault in the kernel module, the processor's run queue at the event node of the fault event has a problem and becomes the fault run queue.

[0126] In this scenario, to recover from the fault, the processor's fault run queue can be cleared. Then, based on the processor's identifier, tasks associated with each processor are selected from the global task list. This means selecting tasks that need to be processed by the target processor within each processor. Following the task processing order within the target processor, the kernel module schedules these tasks to the cleared fault run queue, thus reconstructing the target processor's target run queue. The target processor can be any one of the multiple processors running within the kernel module.

[0127] Furthermore, after constructing the target run queue and determining the recovery function, the execution process of the fault handling function can be skipped, and the recovery function can be called and executed again to handle the pending tasks in the target run queue, thereby achieving automatic fault recovery.

[0128] Alternatively, the kernel module can schedule the task to be processed to the target processor, which can also be achieved in the following ways:

[0129] Determine the fault run queue corresponding to the event node of the fault event for the target processor;

[0130] The fault run queue is cleared, and the i-th pending task in the global task list is scanned and determined according to the order of pending tasks in the global task list. It is determined whether the i-th pending task in the global task list is a pending task associated with the target processor. Here, i is a positive integer less than or equal to n, and i starts from 1. n is the number of pending tasks in the global task list.

[0131] If so, the task to be processed is scheduled to the fault run queue through the kernel module;

[0132] i increments by 1;

[0133] Determine if i is greater than n;

[0134] If not, then continue to execute the process of scheduling the pending task to the fault run queue through the kernel module;

[0135] If so, the fault run queue generated by the scheduling will be used as the target run queue of the target processor.

[0136] Specifically, taking any one of the target processors running in the kernel module as an example, when it is determined that the kernel module has a fault, the run queue of the target processor at the time of the fault can be identified as the fault run queue, and the fault run queue of the target processor can be cleared. Then, based on the identifier of the target processor, the pending tasks associated with the target processor can be filtered from the global task list.

[0137] If the global task list contains n tasks to be processed (n is a positive integer), then i takes the value of 1. That is, starting from the first task to be processed, it is determined whether the first task to be processed is a task to be processed associated with the target processor, that is, whether it needs to be processed by the target processor. If it is determined to be associated, the first task to be processed is scheduled to the cleared fault run queue through the kernel module, and i is incremented by 1. It is then determined whether the value of i after incrementing (2) is greater than n. If it is not greater, it is then determined whether the second task to be processed is a task to be processed associated with the target processor. This process continues until it is determined that the value of i after incrementing is greater than n. Then the process stops and the fault run queue generated by the scheduling is used as the target run queue of the target processor.

[0138] If it is determined that the i-th pending task is not a pending task associated with the target processor, i is incremented by 1, and it is determined whether the value of i after incrementing is greater than n. If it is not greater, it is determined whether the i-th pending task is a pending task associated with the target processor. This process continues until it is determined that the value of i after incrementing is greater than n. At this point, the process stops, and the fault run queue generated by the scheduler is used as the target run queue of the target processor.

[0139] The embodiments in this specification achieve automatic recovery of the scheduler's fault by clearing and rebuilding the run queue corresponding to the target processor when the fault occurs. This avoids the entire operating system crashing and restarting, which helps to improve the service duration of the operating system and improve task processing efficiency.

[0140] Furthermore, the embodiments in this specification utilize stack backtracking technology to identify scheduler failures. Simultaneously, execution is restored to a recoverable function within the call path. Then, by clearing and rebuilding the scheduling queue corresponding to the CPU at the time of the failure, the scheduler's operation is restored, preventing system crashes and restarts caused by scheduler failures. In other words, the automatic recovery method for kernel scheduler failures provided in this specification can maintain the operation of the entire operating system without interruption when the kernel scheduler fails, automatically restoring the scheduler to a running state, reducing the overall operating system downtime, and possessing practical value and high technical advancement.

[0141] In one embodiment of this specification, in response to a fault event of a kernel module, the function call path corresponding to the kernel module is determined. If the fault event is determined to belong to a kernel scheduling function based on the function call path, a repair function in the function call path is determined based on the target processor running the kernel module. The historical state parameters of the target processor calling the repair function are determined and set as the current state parameters of the target processor. The kernel module schedules the task to be processed to the target processor, wherein the target processor calls and executes the repair function based on the current state parameters to process the task to be processed.

[0142] In this embodiment of the specification, when a kernel module malfunctions, specifically when the kernel scheduler (i.e., the scheduling function) is identified as faulty, a repair function for the target processor running on the kernel module is determined based on the kernel module's function call path. The current state of the target processor is then repaired based on its historical state parameters from calling this repair function. The repaired target processor then re-calls and executes the repair function, thereby achieving fault repair. This helps avoid the interruption of upper-layer service operation and subsequent operating system restart due to kernel scheduler failure. Therefore, the fault handling method provided in this embodiment can promptly repair faults, reducing the overall downtime rate of the operating system and ensuring uninterrupted operation, thus improving operational efficiency.

[0143] The following is in conjunction with the appendix Figure 2 Taking the application of the fault handling method provided in this specification in a real-world scenario as an example, the fault handling method will be further explained. Among other things, Figure 2 The present specification shows a flowchart of a fault handling method according to an embodiment, which specifically includes the following steps.

[0144] Step 202: In response to a fault event in the kernel module, call and execute the fault handling function.

[0145] Step 204: Based on the execution process of the fault handling function, backtrack the stack area of ​​the kernel module to obtain the function call path corresponding to the kernel module.

[0146] Step 206: Parse the function call path and determine whether the fault event belongs to a kernel scheduling function based on the parsing result.

[0147] If it is determined that the fault event belongs to a kernel scheduling function, proceed to step 208; if it is determined that the fault event does not belong to a kernel scheduling function, proceed to step 232.

[0148] Step 208: Determine whether the target processor running on the kernel module has acquired the corresponding spinlock at the event node of the fault event.

[0149] Specifically, if the target processor acquires the corresponding spinlock at the event node of the fault event, then proceed to step 210; if the target processor does not acquire the corresponding spinlock at the event node of the fault event, then proceed to step 232.

[0150] Step 210: Based on the target processor, trace back at least one upper-level function of the kernel scheduling function in the function call path.

[0151] Step 212: Determine whether a repair function exists in the at least one upper-level function.

[0152] Specifically, if at least one upper-level function contains a repair function, then step 214 can be executed; if at least one upper-level function does not contain a repair function, then step 232 is executed.

[0153] Step 214: Determine the repair function of the target processor based on the at least one upper-level function.

[0154] Step 216: By backtracking the stack area, determine the historical state parameters of the target processor calling the repair function, and determine the historical state parameters as the current state parameters of the target processor.

[0155] Step 218: Determine the fault run queue corresponding to the event node of the fault event for the target processor.

[0156] Step 220: Clear the fault operation queue.

[0157] Step 222: Scan and determine the global task list according to the order of the tasks to be processed in the global task list.

[0158] Whether the i-th pending task in the list is a pending task associated with the target processor, where i is less than or equal to n.

[0159] A positive integer, where i starts from 1, and n is the number of tasks to be processed in the global task list.

[0160] If yes, proceed to step 224; otherwise, proceed to step 226.

[0161] Step 224: The task to be processed is scheduled to the fault run queue through the kernel module.

[0162] Step 226, increment i by 1.

[0163] Step 228: Determine if i is greater than n.

[0164] If not, return to step 224; if yes, proceed to step 230.

[0165] Step 230: Use the fault run queue generated by the scheduling as the target run queue of the target processor.

[0166] Step 232: Enter the crash process.

[0167] In this embodiment of the specification, when a kernel module malfunctions, specifically when the kernel scheduler (i.e., the scheduling function) is identified as faulty, a repair function for the target processor running on the kernel module is determined based on the kernel module's function call path. The current state of the target processor is then repaired based on its historical state parameters from calling this repair function. The repaired target processor then re-calls and executes the repair function, thereby achieving fault repair. This helps avoid the interruption of upper-layer service operation and subsequent operating system restart due to kernel scheduler failure. Therefore, the fault handling method provided in this embodiment can promptly repair faults, reducing the overall downtime rate of the operating system and ensuring uninterrupted operation, thus improving operational efficiency.

[0168] Corresponding to the above method embodiments, this specification also provides embodiments of a fault handling device. Figure 3 A schematic diagram of a fault handling device according to one embodiment of this specification is shown. Figure 3 As shown, the device includes:

[0169] The first determining module 302 is configured to determine the function call path corresponding to the kernel module in response to a fault event of the kernel module;

[0170] The second determining module 304 is configured to, when determining that the fault event belongs to a kernel scheduling function based on the function call path, determine the repair function in the function call path based on the target processor running the kernel module;

[0171] Processing module 306 is configured to determine the historical state parameters of the target processor calling the repair function, and to determine the historical state parameters as the current state parameters of the target processor;

[0172] The scheduling module 308 is configured to schedule the pending task to the target processor through the kernel module, wherein the target processor calls and executes the repair function based on the current state parameters to process the pending task.

[0173] Optionally, the first determining module 302 is further configured to:

[0174] The stack region of the kernel module is backtracked to obtain the function call path corresponding to the kernel module.

[0175] Optionally, the second determining module 304 is further configured to:

[0176] Based on the target processor running on the kernel module, trace back at least one upper-level function of the kernel scheduling function in the function call path;

[0177] The repair function for the target processor is determined based on the at least one upper-level function, wherein the target processor is any one of the processors running in the kernel module, and the target processor has a history of calling the repair function.

[0178] Optionally, the scheduling module 308 is further configured to:

[0179] Determine the fault run queue corresponding to the event node of the fault event for the target processor;

[0180] Based on the identifier of the target processor, determine the tasks to be processed in the global task list that are associated with the target processor;

[0181] The fault run queue is cleared, and the tasks to be processed are scheduled to the fault run queue according to the task processing order of the tasks to be processed, and the kernel module is used to construct the target run queue of the target processor.

[0182] Optionally, the fault handling device further includes a judgment module, configured to:

[0183] Determine whether the target processor acquires the corresponding spinlock at the event node of the fault event;

[0184] If so, then the second determination module 304 is executed.

[0185] Optionally, the determination module is further configured to:

[0186] If the target processor fails to acquire the corresponding spinlock at the event node of the fault event, the target processor detects whether the spinlock has been released, and acquires the spinlock if the spinlock is detected to have been released.

[0187] Optionally, the second determining module 304 is further configured to:

[0188] Determine whether the at least one upper-level function contains a history call function of the target type;

[0189] If so, the historical call function will be used as the repair function for the target processor.

[0190] Optionally, the fault handling device further includes a parsing module, configured to:

[0191] The stack area of ​​the kernel module is backtracked, and the backtracking results are parsed to generate the historical calls to the repair function and / or the context data generated during the execution process.

[0192] The context data is used as the historical state parameter of the repair function.

[0193] Optionally, the scheduling module 308 is further configured to:

[0194] Determine the fault run queue corresponding to the event node of the fault event for the target processor;

[0195] Clear the fault run queue, and scan and determine whether the i-th task in the global task list is a task associated with the target processor according to the order of the tasks to be processed in the global task list. Here, i is a positive integer less than or equal to n, and i starts from 1. n is the number of tasks to be processed in the global task list.

[0196] If so, the task to be processed is scheduled to the fault run queue through the kernel module;

[0197] i increments by 1;

[0198] Determine if i is greater than n;

[0199] If not, then continue to execute the process of scheduling the pending task to the fault run queue through the kernel module;

[0200] If so, the fault run queue generated by the scheduling will be used as the target run queue of the target processor.

[0201] The above is a schematic scheme of a fault handling device according to this embodiment. It should be noted that the technical solution of this fault handling device and the technical solution of the fault handling method described above belong to the same concept. For details not described in detail in the technical solution of the fault handling device, please refer to the description of the technical solution of the fault handling method described above.

[0202] Figure 4 A structural block diagram of a computing device 400 according to one embodiment of this specification is shown. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0203] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0204] In one embodiment of this specification, the aforementioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0205] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 400 can also be a mobile or stationary server.

[0206] The processor 420 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described fault handling method.

[0207] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described fault handling method belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described fault handling method.

[0208] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described fault handling method.

[0209] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the above-described fault handling method belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described fault handling method.

[0210] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described fault handling method.

[0211] The above is an illustrative example of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the aforementioned fault handling method belong to the same concept. Details not described in detail in the computer program's technical solution can be found in the description of the technical solution of the aforementioned fault handling method.

[0212] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0213] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0214] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0215] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0216] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A fault handling method, comprising: In response to a fault event of a kernel module, the function call path corresponding to the kernel module is determined, wherein the function call path includes functions that have been called in the past; If the fault event is determined to belong to a kernel scheduling function based on the function call path, then the repair function in the function call path is determined based on the target processor running the kernel module. Determine the historical state parameters of the target processor calling the repair function, and set the historical state parameters as the current state parameters of the target processor; The kernel module schedules the pending task to the target processor, wherein the target processor calls and executes the repair function based on the current state parameters to process the pending task.

2. The fault handling method according to claim 1, wherein determining the function call path corresponding to the kernel module includes: The stack region of the kernel module is backtracked to obtain the function call path corresponding to the kernel module.

3. The fault handling method according to claim 1, wherein determining the repair function in the function call path based on the target processor running the kernel module includes: Based on the target processor running on the kernel module, trace back at least one upper-level function of the kernel scheduling function in the function call path; The repair function for the target processor is determined based on the at least one upper-level function, wherein the target processor is any one of the processors running in the kernel module, and the target processor has a history of calling the repair function.

4. The fault handling method according to claim 1, wherein scheduling the task to be processed to the target processor through the kernel module includes: Determine the fault run queue corresponding to the event node of the fault event for the target processor; Based on the identifier of the target processor, determine the tasks to be processed in the global task list that are associated with the target processor; The fault run queue is cleared, and the tasks to be processed are scheduled to the fault run queue according to the task processing order of the tasks to be processed, and the kernel module is used to construct the target run queue of the target processor.

5. The fault handling method according to claim 1, before determining the repair function in the function call path based on the target processor running on the kernel module, further comprising: Determine whether the target processor acquires the corresponding spinlock at the event node of the fault event; If so, then the process based on the target processor running the kernel module is executed to determine whether there is a repair function to be restored in the function call path.

6. The fault handling method according to claim 5 further includes: If the target processor fails to acquire the corresponding spinlock at the event node of the fault event, the target processor detects whether the spinlock has been released, and acquires the spinlock if the spinlock is detected to have been released.

7. The fault handling method according to claim 3, wherein determining the repair function of the target processor based on the at least one upper-level function comprises: Determine whether the at least one upper-level function contains a history call function of the target type; If so, the historical call function will be used as the repair function for the target processor.

8. The fault handling method according to claim 1 further includes: The stack region of the kernel module is backtracked, and the backtracking results are parsed to generate the historical calls to the repair function and / or the context data generated during the execution process. The context data is used as the historical state parameter of the repair function.

9. The fault handling method according to claim 1, wherein scheduling the task to be processed to the target processor through the kernel module comprises: Determine the fault run queue corresponding to the event node of the fault event for the target processor; Clear the fault run queue, and scan and determine whether the i-th task in the global task list is a task associated with the target processor according to the order of the tasks to be processed in the global task list. Here, i is a positive integer less than or equal to n, and i starts from 1. n is the number of tasks to be processed in the global task list. If so, the task to be processed is scheduled to the fault run queue through the kernel module; i increments by 1; Determine if i is greater than n; If not, then continue to execute the process of scheduling the pending task to the fault run queue through the kernel module; If so, the fault run queue generated by the scheduling will be used as the target run queue of the target processor.

10. A fault handling device, comprising: The first determining module is configured to determine the function call path corresponding to the kernel module in response to a fault event of the kernel module, wherein the function call path includes functions that have been called in the past; The second determining module is configured to, when determining that the fault event belongs to a kernel scheduling function based on the function call path, determine the repair function in the function call path based on the target processor running the kernel module; The processing module is configured to determine the historical state parameters of the target processor calling the repair function, and to determine the historical state parameters as the current state parameters of the target processor; The scheduling module is configured to schedule tasks to be processed to the target processor through the kernel module, wherein the target processor calls and executes the repair function based on the current state parameters to process the tasks to be processed.

11. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the fault handling method according to any one of claims 1 to 9.

12. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the fault handling method according to any one of claims 1 to 9.

Images