A Linux kernel soft deadlock intelligent detection method and system based on threshold re-examination

Abstract

This invention discloses a Linux kernel soft deadlock intelligent detection method and system based on threshold re-checking. The method includes: expanding the data structure required for soft deadlock re-checking; using soft deadlock detection parameters as threshold-type re-checking control parameters to determine whether to trigger kernel panic; when a soft deadlock is detected in the current CPU and the soft deadlock re-checking triggering conditions are met, controlling the current CPU to obtain soft deadlock re-checking execution rights and triggering runtime sampling of itself and remote online CPUs; during runtime sampling, collecting the call stack of the current execution context of CPUs with stalled execution progress, and determining the corresponding soft deadlock type based on the critical path characteristics in the call stack; counting the number of CPUs with the same soft deadlock type as the current CPU and comparing them with the threshold-type re-checking control parameters to execute corresponding operations. This invention can improve the accuracy of soft deadlock judgment while taking into account both continuous system operation and fault scene preservation.

Description

Technical Field

[0001] This invention relates to the field of computer operating system kernel fault detection technology, specifically to a Linux kernel soft deadlock intelligent detection method and system based on threshold re-examination. Background Technology

[0002] With the continuous evolution of multi-core architectures and the increasing complexity of kernel execution paths, traditional softlockup detection methods based on watchdog timeout mechanisms, which rely primarily on fixed time thresholds and single-CPU behavior judgments, are gradually becoming inadequate to accurately reflect the true operating state of the system. This mechanism determines that a single CPU may be in a soft deadlock simply because it has not undergone scheduling switching or responded to scheduling events within a preset time window, but it lacks the ability to comprehensively analyze global scheduling topology, cross-CPU dependency links, kernel stack behavior patterns, and current load characteristics.

[0003] Existing Linux kernel softlockup detection mechanisms typically control whether to trigger a panic upon detecting a soft deadlock through configuration parameters. However, these parameters primarily function as a switch to trigger a panic, lacking the ability to re-examine and judge based on the running status of multiple CPUs. In other words, after detecting a softlockup on a CPU, existing mechanisms often struggle to further determine whether the anomaly is a localized stagnation of a single CPU, a short-term load congestion, or a system-level soft deadlock state caused by multiple CPUs for the same reason.

[0004] In modern kernel environments with high concurrency and complex lock dependency chains, a prolonged CPU execution in kernel mode does not necessarily equate to an "unrecoverable deadlock." Behind this deadlock may lie global resource contention, congested reclamation paths, RCU batch processing phases, lock queue waiting, or even transient starvation caused by scheduler load bias. Therefore, detection strategies based solely on timeout thresholds are prone to misjudgment in complex load scenarios.

[0005] Furthermore, in multi-CPU systems, the reasons for the shutdown of different CPUs may differ. Relying solely on the timeout status of a single CPU to determine whether to trigger a panic easily overlooks the differences in cross-CPU behavior; completely disabling the softlockup panic mechanism may prevent timely preservation of the fault context when a real system-level soft deadlock occurs. Therefore, current technology still lacks a review mechanism capable of sampling the runtime state of each online CPU, analyzing the call stack, identifying the soft deadlock type, and counting the number of CPUs with the same type of soft deadlock after a softlockup is triggered.

[0006] In critical business scenarios such as cloud computing, large-scale distributed storage systems, and databases, system continuity and availability typically take precedence over immediate fault termination. A panic caused by misjudgment can directly lead to service interruptions, instance migration, data rebalancing, and even trigger a cascading effect. For stability reasons, business operations often disable the softlockup panic mechanism by default in production environments to reduce the risk of accidental triggering. However, this conservative strategy significantly weakens the kernel's ability to preserve context when dealing with soft deadlocks caused by real kernel defects. Because a panic is not triggered, critical stack traces, register states, and related context information may not be fully recorded, thus affecting problem localization and closed-loop processing, and prolonging the fault repair cycle.

[0007] Therefore, there is an urgent need to introduce a supplementary mechanism to enhance existing softlockup detection capabilities. This mechanism should enable more refined analysis of CPU soft deadlocks through multi-dimensional information collection and hierarchical decision-making, allowing the system to distinguish between different scenarios such as "transient congestion," "recoverable blocking," and "true soft deadlocks." Specifically, without disrupting the existing Linux kernel soft deadlock detection framework, a soft deadlock re-inspection mechanism needs to be introduced. This mechanism should determine whether the current softlockup event constitutes a system-level anomaly by sampling the runtime state of multiple online CPUs, analyzing stack characteristics, and statistically analyzing the number of CPUs with the same type of soft deadlock. Based on this, in the event of a true soft deadlock caused by a kernel defect, key situational information and diagnostic logs can be preserved to support problem localization, while minimizing the risk of misjudgment and avoiding unnecessary kernel panics that could impact business continuity. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide a Linux kernel soft deadlock intelligent detection method and system based on threshold re-examination, in order to improve the accuracy of soft deadlock judgment and take into account both continuous system operation and fault scene preservation.

[0009] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A threshold-based intelligent detection method for Linux kernel soft deadlock includes the following steps: S1, Extend the data structure required for Linux kernel soft deadlock re-examination, the data structure is used to record the running state sampling results and soft deadlock type of each CPU; S2, semantically extend the soft deadlock detection parameters of the Linux kernel, and use the soft deadlock detection parameters as threshold-type re-examination control parameters for whether to trigger kernel panic; S3, when a soft deadlock is detected in the current CPU and the soft deadlock re-check triggering condition is met, control the current CPU to obtain the soft deadlock re-check execution right, and the current CPU triggers the running state sampling of itself and the remote online CPU; S4. During the running sampling process, determine whether there is any stagnation in the running progress of each CPU, collect the call stack of the current execution context of the CPU with stagnation, and determine the corresponding soft deadlock type based on the critical path characteristics in the call stack. S5. Obtain the current CPU's soft deadlock type, count the number of CPUs with the same soft deadlock type as the current CPU to obtain the number of CPUs with the same soft deadlock type, and compare the number of CPUs with the threshold-type re-examination control parameter; if the number of CPUs with the same soft deadlock type is less than the threshold-type re-examination control parameter, then release the soft deadlock re-examination state and maintain system operation; if the number of CPUs with the same soft deadlock type is greater than or equal to the threshold-type re-examination control parameter, then trigger a kernel panic and generate a fault scene file.

[0010] Furthermore, in step S1, the data structures required for expanding the Linux kernel soft deadlock re-examination specifically include: A new softlockup type enumeration variable, softlockup_class, is added to distinguish CPU softlockup types. The softlockup type enumeration variable includes one or more of the following types: no softlockup suspected type, spinlock type, scheduling blocking type, I / O blocking type, RCU type, and undefined type. A new running status record data structure, struct softlockup_cpu_state, is added to record the CPU's running stack and soft deadlock classification information during the soft deadlock re-examination process. The running status record data structure includes one or more of the following: struct stack_trace trace (which records the CPU's current execution stack information at the time of sampling), unsigned long entries (which stores the return address array member of the stack sampling return address), and enumsoftlockup_class sl_class (which records the soft deadlock category). The kernel macro DEFINE_PER_CPU is called to define a global per-CPU state variable sl_state, so that each CPU can independently maintain the state information of the soft deadlock retest phase. Define a global re-examination status variable atomic_t sl_active to indicate whether a soft deadlock re-examination process is currently running in the system.

[0011] Furthermore, in step S2, the semantic extension of the Linux kernel's soft deadlock detection parameters specifically includes: The semantics of the Linux kernel's soft deadlock panic control configuration item `kernel.watchdog_softlockup_panic` are semantically extended, changing it from a boolean control parameter to a threshold-based re-examination control parameter. The extended configuration is as follows: When the threshold-type re-examination control parameter is configured to the first value, it means that the kernel panic behavior is turned off, the soft deadlock re-examination process is not entered, and the system continues to run after only printing alarm information; When the threshold-type re-examination control parameter is configured to a value greater than the first value, it indicates that after a soft deadlock is detected in the CPU, the soft deadlock re-examination process is entered, and whether to trigger a kernel panic is determined based on whether the number of CPUs with the same type of soft deadlock reaches the configured value of the threshold-type re-examination control parameter.

[0012] Furthermore, the threshold-type re-inspection control parameters are determined as follows: During the kernel parameter parsing phase, the configuration values ​​parsed from kernel boot parameters or configuration write operations are subjected to boundary constraints and normalization processing by the softlockup_panic_setup function. The kernel numerical range limiting macro clamp is used to restrict the configuration values ​​to between 0 and the current number of online CPUs, thus obtaining the threshold-type re-examination control parameters. The current number of online CPUs is obtained by the online CPU count acquisition function num_online_cpus.

[0013] Furthermore, when the kernel watchdog timer processing path watchdog_timer_fn detects a soft deadlock in the CPU and the threshold-type re-examination control parameter is set to a value representing the activation of the soft deadlock re-examination process, step S3 is executed. Step S3 specifically includes: The global re-examination status atomic variable sl_active is used to determine whether the current CPU meets the soft deadlock re-examination triggering condition: when the global re-examination status atomic variable indicates that a CPU is already executing the soft deadlock re-examination process, the re-examination process is not triggered; when the global re-examination status atomic variable indicates that there is no soft deadlock re-examination process, the global re-examination status atomic variable is set to the re-examination running state through atomic operations, so that the current CPU obtains the right to execute the soft deadlock re-examination. After the current CPU obtains the right to perform soft deadlock re-examination, it calls the sampling callback function sl_collect_ipi, which performs running sampling, to complete the current CPU's stack sampling and soft deadlock classification. Then, it calls the kernel interface function smp_call_function_many, which sends function call requests to multiple CPUs, to send a request to the remote online CPU to trigger the remote online CPU to execute the sampling callback function.

[0014] Furthermore, in step S4, determining whether each CPU experiences a stall in its operation specifically includes: If the task currently running on the CPU is an idle task, then it is determined that the current CPU does not have any suspicion of stalling. If the difference between the current timestamp obtained by the current timestamp acquisition function get_timestamp and the timestamp of the last confirmed running progress of the current CPU obtained by the per-CPU variable access macro per_cpu is less than a preset multiple of the soft deadlock watchdog detection period sample_period, then it is determined that the current CPU does not have any suspicion of stalling. If none of the above conditions are met, then it is determined that the current CPU has stalled.

[0015] Further, in step S4, the call stack of the current execution context of the CPU where the execution progress has stalled is collected, and the corresponding soft deadlock type is determined based on the critical path characteristics in the call stack. Specifically, this includes: The stack record members in the current CPU's runtime status record data structure are initialized. The member `trace.nr_entries`, representing the number of recorded stack entries, is set to its initial value. The member `trace.max_entries`, which limits the maximum sampling depth, is set to the preset maximum sampling depth. The member `trace.entries`, which points to the return address storage buffer, is set to point to the return address array. Then, the kernel interface function `save_stack_trace`, which performs call stack backtracking sampling, is called to sample the call chain of the current CPU's execution context. A loop iterating through the call stack entries performs critical path feature matching on the sampling results. Based on the matching results, the corresponding soft deadlock type is determined. When the call stack contains the spinlock-related function `spin_lock`, the soft deadlock type is determined to be a spinlock type; when the call stack contains scheduling-related paths, the soft deadlock type is determined to be a scheduling blocking type; when the call stack contains I / O waiting paths, the soft deadlock type is determined to be an I / O blocking type; when the call stack contains RCU-related functions, the soft deadlock type is determined to be an RCU type; when no preset characteristic function is matched, the soft deadlock type is determined to be an undefined type.

[0016] Further, in step S5, obtaining the soft deadlock type of the current CPU includes: reading the soft deadlock type classification result from the running status record data structure corresponding to the current CPU by obtaining the kernel interface macro this_cpu_ptr of the CPU variable instance address on the current CPU, and using the soft deadlock type classification result as the benchmark type for this re-examination statistics and decision-making; The process of counting the number of CPUs with the same soft deadlock type as the current CPU to obtain the number of CPUs with the same soft deadlock includes: defining a count variable sl_count for the number of CPUs with the same soft deadlock, and iterating through all online CPUs using a kernel traversal macro. During the traversal, the kernel interface macro per_cpu_ptr, which obtains the address of the CPU variable corresponding to a specified CPU, is used to obtain the soft deadlock type classification result for each online CPU. If the soft deadlock type of an online CPU is consistent with the baseline type, the value of the count variable for the number of CPUs with the same soft deadlock is incremented.

[0017] A threshold-based intelligent detection system for Linux kernel soft deadlock includes a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute the steps of a threshold-based intelligent detection method for Linux kernel soft deadlock.

[0018] A computer-readable storage medium storing a computer program / instructions programmed or configured to execute, via a processor, the steps of a threshold-based intelligent detection method for Linux kernel soft deadlock.

[0019] Compared with the prior art, the advantages of the present invention are as follows: This invention establishes the necessary data foundation for re-inspection, enabling the recording, traceability, and comparison of the operating status of each CPU. By expanding the soft deadlock detection parameters into threshold-based re-inspection control parameters, the soft deadlock handling strategy can be flexibly configured according to the actual system state. Unified control of the re-inspection triggering process ensures the orderly execution of the re-inspection process. Analysis of CPU operation progress and call stack characteristics allows for more precise soft deadlock type judgment. By statistically analyzing the number of CPUs with similar soft deadlocks and comparing thresholds, the system can make decisions based on the anomaly range, deciding whether to continue operation or preserve the fault scene. This invention forms a closed-loop detection mechanism from triggering, re-inspection, classification to decision-making, improving the accuracy and controllability of Linux kernel soft deadlock judgment and handling, while enhancing the ability to preserve the fault scene while ensuring continuous system operation. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the overall handling process for existing Linux kernel soft deadlocks.

[0021] Figure 2 This is an overall flowchart of the Linux kernel soft deadlock intelligent detection method based on threshold re-examination according to an embodiment of the present invention.

[0022] Figure 3 This is a flowchart illustrating the intelligent detection method for Linux kernel soft deadlock based on threshold re-examination in a specific application embodiment. Detailed Implementation

[0023] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0024] The following are definitions of some abbreviations and key terms in this invention: Softlockup, also known as soft deadlock, refers to an abnormal state where a CPU continues to run for an extended period without a valid scheduling switch, meaning the scheduler is unable to obtain an execution opportunity for a prolonged time. It typically manifests as the CPU remaining stuck in a certain kernel execution path; while the overall system continues to run, this particular core has lost its normal scheduling progress. Common triggers include kernel spinlock deadlocks, prolonged disabling of preemption or interrupts, and RCU critical section stagnation; similar phenomena may also occur under high system load or prolonged execution of high-priority kernel paths. Softlockup does not mean the CPU has completely stopped working, but rather that the system has a potential livelock or impeded progress problem.

[0025] Panic: Also known as kernel panic, panic is an emergency termination mechanism triggered by the operating system when it detects an unrecoverable system-level anomaly or risk of inconsistency breach. Its function is to stop the system from executing and output critical diagnostic information, thereby preventing the error from spreading further.

[0026] vmcore: vmcore is a memory image file generated after the operating system triggers a panic. It records the runtime state at the moment of system crash. The file contains kernel address space, CPU registers, process context, stack information, and key data structures, providing support for subsequent fault location and root cause analysis. With vmcore, developers can reconstruct the system crash scene in an offline environment, analyze deadlocks, memory corruption, illegal access, or scheduling anomalies, effectively avoiding the risk of missing information due to relying solely on real-time logs.

[0027] IPI: IPI, also known as Inter-Processor Interrupt, is a hardware interrupt signal actively sent by one CPU to other CPUs in a multiprocessor system. It triggers the target CPU to immediately execute specific processing logic. Its function is to achieve cross-CPU cooperation and synchronization in a multi-core environment, such as waking up a remote CPU, executing function callbacks, or performing global state sampling, thereby ensuring data consistency and operational coordination in concurrent execution scenarios.

[0028] The existing Linux kernel's softlockup detection mechanism is based on a time threshold model. The overall flowchart of the Linux kernel soft deadlock handling process before optimization is as follows: Figure 1 As shown, when a CPU fails to perform a scheduling switch or report scheduling progress for an extended period within a preset time window, it is considered to have experienced a softlockup event. There are two main handling strategies after a softlockup is triggered: one is to simply print an alarm message without triggering any other processing, allowing the system to continue running; the other is to directly call `panic()` to trigger a system crash, generating a VMcore log for fault location. While the former avoids accidental restarts, it cannot generate complete fault scene information when the system enters a true unrecoverable soft deadlock state, thus affecting root cause analysis. The latter, while helping to preserve the fault scene, may cause some CPUs to experience temporary operational pauses due to resource contention, lock contention, or interrupt delays under high load or specific business pressure scenarios, leading to misjudgments as softlockups and false panics, thus reducing overall system stability.

[0029] Existing technologies have addressed the causes and handling of kernel soft deadlocks. For example, Chinese invention patent "A method for analyzing kernel soft deadlocks, a processor, and a computing device" (application number CN202410059977.4) discloses a soft deadlock analysis method based on thread and lock information. However, this approach focuses on lock dependency analysis after a soft deadlock occurs, primarily analyzing the thread that triggered the soft deadlock and the target lock it is waiting for. It does not perform thresholding semantic extensions on the original Linux kernel softlockup detection parameters, nor does it perform runtime sampling, call stack feature classification, and count the number of CPUs with similar soft deadlocks on multiple online CPUs after softlockup is triggered. Therefore, this approach struggles to determine whether the current soft deadlock is a localized CPU stagnation or a system-wide anomaly, and it cannot determine whether to maintain system operation or trigger a kernel panic to preserve the fault scene based on multi-CPU re-inspection results.

[0030] Chinese invention patent "A Kernel Soft Deadlock Handling Method, Apparatus, Device, and Storage Medium" (application number CN202111257198.8) discloses a soft deadlock handling method based on watchdog threads and non-maskable interrupts. However, this solution focuses on process priority adjustment and automatic recovery after a soft deadlock is detected. Its approach involves intervening in the target process through non-maskable interrupts, allowing the watchdog thread to regain its running opportunity. This solution does not construct a threshold-based re-examination mechanism for softlockuppanic control parameters, nor does it identify the call stack characteristics and soft deadlock types of each CPU through cross-CPU runtime sampling, nor does it determine whether the system has entered a system-level unrecoverable state based on the number of CPUs with the same type of soft deadlock. Therefore, this solution is more focused on recovery after a soft deadlock, cannot achieve hierarchical decision-making, and is difficult to selectively trigger kernel panics and generate fault scene files when a real system-level soft deadlock occurs.

[0031] In summary, while existing solutions can perform lock relationship analysis or attempt automatic recovery after a soft deadlock occurs, none of them form a complete processing mechanism of "soft deadlock detection parameter threshold configuration - re-inspection process triggering - multi-CPU runtime sampling - soft deadlock type classification - similar CPU quantity statistics - kernel panic level decision-making". It is difficult to accurately distinguish between local soft deadlock and system-level soft deadlock in complex multi-core scenarios, and it is also difficult to meet the needs of continuous system operation and fault scene preservation.

[0032] To address the aforementioned technical issues, this invention introduces an intelligent soft deadlock re-examination mechanism. By adding a unified re-examination and evaluation phase after a soft deadlock is triggered, a secondary analysis and evaluation of the softlockup event is performed to distinguish between "single-core overload-type stagnation" and "systemic soft deadlock anomaly." Specifically, the semantics of the existing softlockup detection control parameters in the Linux kernel are first semantically extended. While retaining the original value semantics, extended configurations are introduced. When the extended configuration is enabled, when the system detects a softlockup event on a CPU, a soft deadlock re-examination logic is added. This logic assesses whether there is a group of abnormal behaviors with similar stack characteristics, involving multiple cores simultaneously experiencing similar stagnation. If multiple CPUs are confirmed to have the same type of stagnation, and the anomaly scale reaches a preset threshold, it is determined to be a system-level soft deadlock state, triggering a panic to generate a vmcore file for subsequent root cause analysis. If it is only a local stagnation or short-term overload of an individual CPU, only an alarm message is printed, the re-examination process is terminated, and the system continues to run. This mechanism achieves a better balance between system stability and fault diagnosability, effectively reducing the false trigger rate under high load scenarios, while ensuring that complete fault scene information can still be preserved when a real system-level soft deadlock occurs.

[0033] like Figure 2 As shown in the figure, the Linux kernel soft deadlock intelligent detection method based on threshold re-checking in this embodiment includes the following steps: S1, Soft deadlock related data structure extension: Extend the data structure required for Linux kernel soft deadlock re-examination. The data structure is used to record the running state sampling results and soft deadlock type of each CPU. S2, Soft deadlock detection parameters and policy configuration extension: semantic extension of the soft deadlock detection parameters in the Linux kernel, using the soft deadlock detection parameters as threshold-type re-examination control parameters for whether to trigger kernel panic; S3, Soft deadlock re-examination process trigger: When a soft deadlock is detected in the current CPU and the soft deadlock re-examination triggering conditions are met, the current CPU is controlled to obtain the soft deadlock re-examination execution right, and the current CPU triggers the running state sampling of itself and the remote online CPU. S4, CPU runtime sampling and stack feature analysis: During runtime sampling, it is determined whether each CPU has stalled execution, the call stack of the current execution context of the CPU with stalled execution is collected, and the corresponding soft deadlock type is determined based on the critical path features in the call stack. S5, System Anomaly Assessment and Fault Control Decision: Obtain the current CPU's soft deadlock type, count the number of CPUs with the same soft deadlock type to obtain the number of CPUs with the same soft deadlock type, and compare the number of CPUs with the same soft deadlock type with the threshold-type re-examination control parameter; if the number of CPUs with the same soft deadlock type is less than the threshold-type re-examination control parameter, then the soft deadlock re-examination state is lifted and the system operation is maintained; if the number of CPUs with the same soft deadlock type is greater than or equal to the threshold-type re-examination control parameter, then a kernel panic is triggered and a fault scene file is generated.

[0034] In this embodiment, as Figure 3 As shown, step S1 (soft deadlock-related data structure extension) extends the necessary data structures without disrupting the existing soft deadlock detection mechanism in the kernel, in order to support the global analysis capabilities of the soft deadlock re-examination phase. The specific data structures required for extending the Linux kernel soft deadlock re-examination include: A new soft deadlock type enumeration variable, `softlockup_class`, has been added to differentiate CPU soft deadlock types, enabling the determination of cross-CPU behavioral similarity during the review phase. The soft deadlock type enumeration variable includes one or more of the following types: no suspected soft deadlock, spinlock type, scheduling blocking type, I / O blocking type, RCU type, and undefined type. Specifically, `STALL_NONE` indicates no suspected CPU soft deadlock; `STALL_SPIN` indicates a soft deadlock caused by spinlock waiting; `STALL_SCHED` indicates a soft deadlock caused by an abnormal scheduling path or prolonged entrapment in scheduling-related code; `STALL_IOWAIT` indicates a soft deadlock caused by prolonged blocking on the I / O waiting path or during related callback processing; `STALL_RCU` indicates a soft deadlock caused by the CPU being stuck in the RCU critical section; and `STALL_UNKNOWN` indicates a soft deadlock type that cannot be clearly categorized based on the current call stack characteristics.

[0035] A new running status record data structure, struct softlockup_cpu_state, is added to record the CPU's running stack and soft deadlock classification information in the soft deadlock re-examination process. The running status record data structure includes one or more of the following: struct stack_trace trace (which records the CPU's current execution stack information at the time of sampling, serving as the original basis for subsequent soft deadlock type classification analysis), unsigned long entries

[16] (which stores the return address array obtained from stack sampling), and enum softlockup_class sl_class (which records the soft deadlock category derived from the execution path analysis, and is the core field for subsequent statistics of the same type of soft deadlock).

[0036] The kernel macro `DEFINE_PER_CPU(struct softlockup_cpu_state, sl_state)` defines the global per-CPU state variable `sl_state`, allowing each CPU to independently maintain its state information during the soft deadlock re-examination phase. `sl_state` stores stack snapshots and soft deadlock classification results during re-examination sampling. `DEFINE_PER_CPU()` is a Linux kernel macro used to define per-CPU variables.

[0037] Define a global re-examination status variable `atomic_t sl_active` to indicate whether a soft deadlock re-examination process is currently running in the system. Atomic operations are used to control the entry and exit of the soft deadlock re-examination process, ensuring that only one soft deadlock re-examination instance exists at a time. This avoids issues such as duplicate sampling or statistical chaos when multiple CPUs trigger concurrently.

[0038] In this embodiment, as Figure 3 As shown, step S2 (soft deadlock detection parameter and policy configuration extension) extends the semantics of the current kernel's `kernel.watchdog_softlockup_panic` configuration while maintaining the existing soft deadlock detection framework. In the current kernel implementation, this parameter is used only as a boolean variable: 0 indicates that panic behavior is disabled, and 1 indicates that a panic is triggered upon detecting a soft deadlock. After the extension, this parameter will no longer be used only as a boolean switch, but will instead serve as a threshold-type configuration parameter (judgment threshold) for kernel soft deadlocks, driving subsequent soft deadlock re-detection and decision-making logic. The semantic extension of the Linux kernel's soft deadlock detection parameters specifically includes: The semantics of the Linux kernel's soft deadlock panic control configuration item `kernel.watchdog_softlockup_panic` are semantically extended, changing it from a boolean control parameter to a threshold-based re-examination control parameter. The extended configuration is as follows: When the threshold-type re-examination control parameter is configured to the first value (e.g., 0), it means that the kernel panic behavior is turned off, the soft deadlock re-examination process is not entered, and the system continues to run after only printing alarm information (consistent with the existing soft deadlock handling behavior of the Linux kernel). When the threshold-type re-check control parameter is configured to a value greater than the first value (e.g., N>1), it indicates that after a soft deadlock is detected in the CPU, a soft deadlock re-check process is initiated. The process determines whether to trigger a kernel panic based on whether the number of CPUs with the same type of soft deadlock reaches the configured value of the threshold-type re-check control parameter. If the number of CPUs with the same type of soft deadlock is greater than or equal to N, a panic is triggered to force a system crash and collect logs; if this number is not reached, only an alarm message is printed, and the system continues to run.

[0039] Optionally, when the threshold-type re-inspection control parameter is configured to 1, it indicates that a panic is forced to crash and logs are collected (consistent with the existing soft deadlock handling behavior of the Linux kernel).

[0040] In this embodiment, the threshold-type re-inspection control parameter is determined by configuring value validity constraints, as follows: During the kernel parameter parsing phase, the configuration values ​​parsed from kernel boot parameters or configuration write operations are subjected to boundary constraints and normalization by the soft deadlock panic parameter parsing function `softlockup_panic_setup` to ensure they are within a legal range. The kernel numerical range limiting macro `clamp` restricts the configuration value to between 0 and the current number of online CPUs, resulting in a threshold-type re-examination control parameter. Specifically, `softlockup_panic = clamp(val, 0, num_online_cpus())`. This constraint prevents abnormal thresholds (such as negative numbers or values ​​exceeding the total number of CPUs) from causing logical failures or distorted judgments, thus ensuring that the threshold semantics match the system scale. Here, `softlockup_panic` is a global configuration variable in the kernel, corresponding to the configuration parameter `kernel.watchdog_softlockup_panic`; `clamp()` is a numerical range limiting macro in the kernel; `val` is the user input value parsed from kernel boot parameters or configuration write operations; and `num_online_cpus()` is a kernel-implemented function that returns the current number of online CPUs in the system.

[0041] When the kernel detects a softlockup on a CPU, if the soft deadlock re-check function is enabled, the final decision-making logic will be postponed to the soft deadlock re-check stage for unified processing. Specifically, in the kernel's watchdog_timer_fn() processing path: when softlockup_panic > 0, the system will not immediately trigger a panic, but will instead enter the soft deadlock re-check process in step S3. During the re-check stage, the re-check logic will sample and analyze the operating status of multiple CPUs, and combine this with the soft deadlock classification statistics to conduct a comprehensive evaluation, ultimately deciding whether to trigger a panic based on threshold judgment conditions.

[0042] It is understood that this embodiment semantically extends the existing softlockup detection control parameters in the Linux kernel. While retaining the original semantics of the 0 and 1 values, extended configurations are introduced. When the extended configuration is enabled, after the system detects a softlockup characteristic on a CPU, it will enter a soft deadlock re-check phase. By evaluating the overall system operating status, it determines the subsequent execution strategy: either output only an alarm message and continue running, or trigger a panic to force a shutdown and collect fault logs. This allows for the introduction of a configurable re-check mechanism without changing the basic semantics of the original softlockup parameters. This enables the system to first perform an overall status assessment after detecting soft deadlock characteristics before deciding whether to continue running with an alarm or trigger a panic, thus balancing business continuity and the need to preserve the fault scene.

[0043] In this embodiment, when the kernel watchdog timer processing path `watchdog_timer_fn` detects a soft deadlock in the CPU and the threshold-type re-check control parameter is set to a value representing the activation of the soft deadlock re-check process, step S3 is executed, such as... Figure 3 As shown, step S3 (soft deadlock re-check process triggering) specifically includes: S31. Check if the current CPU is qualified to trigger a re-check. The global re-check status atomic variable `sl_active` is used to determine if the current CPU meets the soft deadlock re-check triggering conditions, thus controlling the concurrency of the re-check process. When the global re-check status atomic variable indicates that a CPU is already executing a soft deadlock re-check process (e.g., `sl_active` is not 0), it means that a CPU is already executing the re-check process. In this case, the current process ends directly, the current CPU only records the alarm information and exits, without triggering the re-check process, avoiding multiple CPUs concurrently triggering the soft deadlock re-check process. When the global re-check status atomic variable indicates that there is no soft deadlock re-check process (e.g., `sl_active` is 0), the global re-check status atomic variable is set to the re-check running state through an atomic operation (e.g., setting `sl_active` to 1), marking the re-check process as running, allowing the current CPU to obtain the soft deadlock re-check execution right, thereby ensuring that only one CPU can start the re-check logic at a time, and then continuing to step S32.

[0044] S32, complete the current CPU sampling and stack analysis. After the current CPU obtains the right to execute the soft deadlock re-check, it initiates the global soft deadlock re-check operation as the main re-check CPU. The current CPU will first execute its own running state sampling, directly calling the sampling callback function sl_collect_ipi() to complete the current CPU's stack sampling and soft deadlock classification (the specific implementation and classification logic of this function will be explained in detail in step S4).

[0045] S33, trigger cross-CPU runtime sampling. After completing local CPU sampling, the kernel interface function `smp_call_function_many(cpu_online_mask, sl_collect_ipi,...)`, which sends function call requests to multiple CPUs, is called to send IPI requests to all remote online CPUs, triggering the remote online CPUs to execute the lightweight runtime sampling callback function `sl_collect_ipi()`. The specific implementation of the `sl_collect_ipi()` callback function and the soft deadlock classification logic will be completed in step S4; `cpu_online_mask` represents a bitmap of all currently online CPUs; `smp_call_function_many()` is a kernel-provided function used to send IPIs to multiple specified CPUs, causing these CPUs to execute the same callback function in their respective contexts.

[0046] Understandably, during the soft deadlock re-examination phase, the system samples the runtime stack and analyzes the execution progress of all online CPUs to assess whether each CPU is suspected of experiencing execution stagnation. It also extracts call stack characteristics and exception types from each CPU to count the number of CPUs experiencing similar execution stagnation as those that triggered the soft deadlock. By performing a unified re-examination of all online CPUs, the system can expand from single-point anomalies to global runtime status assessment and identify the range of similar stagnation patterns by combining call stack characteristics. This improves the accuracy of soft deadlock detection and provides a more reliable basis for determining whether a panic has been triggered.

[0047] In this embodiment, as Figure 3 As shown, step S4 involves CPU runtime sampling and stack feature analysis. The logic for CPU runtime sampling and stack feature analysis is implemented by the `sl_collect_ipi()` function, which is triggered by step S3. Its main objective is to confirm whether any CPU is experiencing runtime stagnation in a soft deadlock scenario, and to classify the type of stagnation by sampling the call stack, providing a basis for subsequent decision-making. Step S4 specifically includes: S41, obtain the CPU's softlockup state information. The soft deadlock running state record structure corresponding to the CPU is obtained through `struct softlockup_cpu_state *s =this_cpu_ptr(&sl_state)`. This structure is used to store the call stack information and soft deadlock classification results of this sampling.

[0048] S42, determine if there is any suspicion of stagnation in the execution progress of each CPU. Before entering the call stack sampling, the current CPU's running status needs to be quickly determined. The determination rules are as follows: If the task currently running on the CPU is an idle task, it is determined that there is no suspicion of stagnation in the execution progress, and s->sl_class is set to STALL_NONE and the process returns directly; if the difference between the current timestamp obtained by the current timestamp acquisition function get_timestamp() and the timestamp per_cpu(watchdog_touch_ts,cpu) obtained by accessing the per-CPU variable macro per_cpu, which is the last time that the current CPU confirmed that there was execution progress, is less than a preset multiple of the soft deadlock watchdog detection period sample_period (for example, the difference is less than 2 times sample_period), it indicates that scheduling progress can still be observed in multiple detection periods, and it is determined that there is no suspicion of stagnation in the execution progress, and s->sl_class is also set to STALL_NONE and the process returns directly; if none of the above conditions are met, it is determined that the current CPU has a suspicion of stagnation in the execution progress, and the process proceeds to step S43. Among them, get_timestamp() is a kernel function used to obtain the current timestamp; per_cpu() is a kernel-provided per-CPU access macro used to obtain an instance copy of the corresponding variable on a specified CPU; watchdog_touch_ts is a kernel function that records the timestamp of the last confirmed running progress on this CPU; sample_period is the detection cycle of the kernel softlockup watchdog.

[0049] It should be noted that the determination of whether a CPU is suspected of being stalled can be based on the analysis of scheduling progress. Specifically, this involves assessing the CPU's execution status by detecting whether scheduling progress occurs within a specific time window. In particular, if a CPU runs continuously in kernel mode for an extended period without any scheduling switch or scheduling time update, it can be considered to be suspected of stalling. This determination logic is similar to the softlockup time threshold detection mechanism, both relying on scheduling progress to determine whether a CPU is stalling, but the criteria are more lenient. For example, if the existing softlockup mechanism classifies a soft deadlock event as occurring if no scheduling progress occurs within 20 seconds, a shorter warning time window (e.g., 5 seconds) can be set to determine the suspected stalling state.

[0050] S43, Initialize call stack sampling parameters. Before performing call stack sampling, the stack record members in the stack_trace data structure corresponding to the current CPU's running status record need to be initialized. Set the member s->trace.nr_entries, which represents the number of recorded stacks, to the initial value (e.g., 0) to initialize the number of currently recorded stacks; set the member s->trace.max_entries, which limits the maximum sampling depth, to the preset maximum sampling depth (e.g., 16); and set the member trace.entries, which points to the return address storage buffer, to the return address array. Specifically, the call stack storage buffer is specified by s->trace.entries = &(s->entries[0]) to ensure that the backtracking result can be correctly written to the pre-allocated array.

[0051] S44, Sample the current CPU execution stack. The kernel interface function `save_stack_trace(&s->trace)`, which performs call stack backtracking sampling, is called to sample the call chain of the current CPU's execution context and save the backtracked instruction addresses to `s->entries[]`. This call only records the call stack and does not perform symbol resolution or output. `save_stack_trace()` is a kernel-provided call stack backtracking interface function used to sample the execution context on the current CPU and save the backtracked instruction addresses sequentially into the `stack_trace` structure provided by the caller.

[0052] S45, analyze the sampling results and determine the type of soft deadlock. This is done by iterating through the loop statements in the call stack: for (int i = 0; i ... ) ... <s->`trace.nr_entries; i++)` iterates through the call stack, performs critical path feature matching on the sampling results, and determines the corresponding soft deadlock type based on the matching results: When the call stack contains spinlock-related functions such as `spin_lock`, it is determined that the CPU is experiencing a soft deadlock due to spinlock contention, and `s->sl_class = STALL_SPIN` is set to identify the soft deadlock type as a spinlock. When the call stack contains `schedule` or scheduling-related paths, it is determined that the CPU is experiencing a soft deadlock due to scheduling exceptions or waiting, and `s->sl_class = STALL_SCHED` is set to identify the soft deadlock type as a scheduling blocking type. When the call stack contains I / O waiting paths such as `io_schedule`, it is determined that the CPU is experiencing a soft deadlock due to I / O blocking, and `s->sl_class = STALL_IOWAIT` is set to identify the soft deadlock type as an I / O blocking type. When the call stack contains RCU-related functions, it is determined that the CPU is stuck in the RCU critical section, and `s->sl_class = STALL_RCU` is set to identify the soft deadlock type as an RCU type. If no explicit preset characteristic function is matched after the traversal, it is marked as `s->sl_class = ...`. STALL_UNKNOWN determines the soft deadlock type as an undefined type.

[0053] In this embodiment, as Figure 3 As shown, step S5 (system anomaly assessment and fault control decision) specifically includes: S51. Obtain the soft deadlock type of the current CPU. The soft deadlock type classification result is read from the runtime state record data structure corresponding to the current CPU using the kernel interface macro `this_cpu_ptr`, which retrieves the address of the CPU variable instance on the current CPU. This classification result is used as the baseline type for this review and statistical decision-making. Specifically, by calling `int sl_class = this_cpu_ptr(&sl_state)->sl_class`, the soft deadlock classification result is read from the soft deadlock (softlockup) state record structure corresponding to the current CPU. This value will be used as the baseline category for this review and statistical decision-making, and will be used for subsequent cross-CPU similarity comparisons. Here, `this_cpu_ptr()` is a kernel-provided per-CPU variable access interface macro used to obtain the address of a per-CPU variable instance on the current CPU.

[0054] S52, count the number of CPUs with the same soft deadlock type as the current CPU to obtain the number of CPUs with the same type of soft deadlock. Define a counter variable `int sl_count` to count the number of CPUs with the same type of soft deadlock and initialize it to 0. Then, iterate through all online CPUs using the kernel traversal macro `for_each_online_cpu(cpu)`. During the traversal, obtain the soft deadlock type classification result for each online CPU by using the kernel interface macro `per_cpu_ptr` to obtain the CPU variable address corresponding to the specified CPU. Specifically, call `struct softlockup_cpu_state *st = per_cpu_ptr(&sl_state, cpu)` to obtain the `softlockup_cpu_state` structure corresponding to the target CPU. If the soft deadlock type of the online CPU is consistent with the base type, that is, `st->sl_class` is equal to `sl_class`, then it is determined that the CPU and the current CPU have the same type of soft deadlock, and the value of the counter variable `sl_count` is incremented by 1. Among them, for_each_online_cpu() is a kernel-provided CPU traversal macro used to traverse all CPUs currently online; per_cpu_ptr() is a kernel-provided per-CPU variable access interface macro used to obtain the address of a per-CPU variable instance on a specified CPU.

[0055] S53. Compare with the configured threshold. Compare the statistically obtained sl_count with the system-configured threshold softlockup_panic: If sl_count is less than softlockup_panic, it indicates that the number of CPUs experiencing the same type of soft deadlock is still within the system's tolerable range, which can be determined as a local or transient anomaly. In this case, sl_active is set to 0 to remove the re-examination state, and the system continues to run; If sl_count is greater than or equal to softlockup_panic, it indicates that the number of CPUs experiencing soft deadlock for the same reason has reached or exceeded the system's tolerable threshold, which can be determined that the system may enter a system-level deadlock or unrecoverable state. In this case, the panic() function is called to actively trigger a crash to generate a vmcore for subsequent root cause analysis and problem localization.

[0056] Understandably, decisions are made based on statistical results: if only a local CPU shows signs of stagnation, meaning the statistical results have not reached a preset threshold, the system continues to run, only printing alarm information; if multiple CPUs simultaneously show the same type of stagnation, meaning the statistical results have reached a preset threshold, it is determined to be a system-level soft deadlock, triggering a panic to generate a vmcore file for subsequent root cause analysis. By making tiered decisions based on the number of CPUs with the same type of stagnation, the system can distinguish between local anomalies and system-level soft deadlocks; it maintains system operation when the anomaly range is small, avoiding unnecessary downtime; and when the anomaly reaches a threshold, it promptly triggers a panic and generates a vmcore, ensuring subsequent fault localization.

[0057] Compared with the prior art, the present invention has the following beneficial effects: This invention employs multi-dimensional review and hierarchical decision-making to comprehensively analyze CPU operating status and call stack, effectively distinguishing between "recoverable blocking" and "true soft deadlock," significantly reducing the probability of false triggering. Traditional mechanisms may frequently trigger system restarts under complex load scenarios, thus affecting business continuity. This invention, by introducing a review process and decision control logic, ensures the system continues to run in recoverable scenarios, only executing a panic when an unrecoverable risk is confirmed, thereby reducing unnecessary downtime. Furthermore, this invention exhibits good compatibility with existing kernel mechanisms, enhancing the existing softlockup detection framework while maintaining its core functionality. It upgrades capabilities by extending the state structure and decision logic, reducing invasiveness to the main kernel process and facilitating subsequent integration and maintenance.

[0058] The present invention further provides a Linux kernel soft deadlock intelligent detection system based on threshold re-examination, comprising a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the steps of the Linux kernel soft deadlock intelligent detection method based on threshold re-examination.

[0059] The present invention further provides a computer-readable storage medium storing a computer program / instructions, the computer program / instructions being programmed or configured to execute, via a processor, the steps of a threshold-based intelligent detection method for Linux kernel soft deadlock.

[0060] The system and medium of the present invention, corresponding to the methods described above, also have the advantages described above.

[0061] The present invention can implement all or part of the processes in the methods of the above embodiments, or it can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. Computer-readable media include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. The memory is used to store computer programs and / or modules. The processor implements various functions by running or executing the computer programs and / or modules stored in the memory, and by calling data stored in the memory. The memory may include high-speed random access memory, as well as non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital (SD) cards, flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0062] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A Linux kernel soft deadlock intelligent detection method based on threshold re-examination, characterized in that, Including the following steps: S1, Extend the data structure required for Linux kernel soft deadlock re-examination, the data structure is used to record the running state sampling results and soft deadlock type of each CPU; S2, semantically extend the soft deadlock detection parameters of the Linux kernel, and use the soft deadlock detection parameters as threshold-type re-examination control parameters for whether to trigger kernel panic; S3, when a soft deadlock is detected in the current CPU and the soft deadlock re-check triggering condition is met, control the current CPU to obtain the soft deadlock re-check execution right, and the current CPU triggers the running state sampling of itself and the remote online CPU; S4. During the running sampling process, determine whether there is any stagnation in the running progress of each CPU, collect the call stack of the current execution context of the CPU with stagnation, and determine the corresponding soft deadlock type based on the critical path characteristics in the call stack. S5. Obtain the current CPU's soft deadlock type, count the number of CPUs with the same soft deadlock type as the current CPU to obtain the number of CPUs with the same soft deadlock type, and compare the number of CPUs with the threshold-type re-examination control parameter; if the number of CPUs with the same soft deadlock type is less than the threshold-type re-examination control parameter, then release the soft deadlock re-examination state and maintain system operation; if the number of CPUs with the same soft deadlock type is greater than or equal to the threshold-type re-examination control parameter, then trigger a kernel panic and generate a fault scene file.

2. The intelligent detection method for Linux kernel soft deadlock based on threshold re-examination according to claim 1, characterized in that, In step S1, the data structures required for expanding the Linux kernel soft deadlock re-examination specifically include: A new softlockup type enumeration variable, softlockup_class, is added to distinguish CPU softlockup types. The softlockup type enumeration variable includes one or more of the following types: no softlockup suspected type, spinlock type, scheduling blocking type, I / O blocking type, RCU type, and undefined type. A new running status record data structure, struct softlockup_cpu_state, is added to record the CPU's running stack and soft deadlock classification information during the soft deadlock re-examination process. The running status record data structure includes one or more of the following: struct stack_trace trace (which records the CPU's current execution stack information at the time of sampling), unsigned long entries (which stores the return address array member of the stack sampling return address), and enumsoftlockup_class sl_class (which records the soft deadlock category). The kernel macro DEFINE_PER_CPU is called to define a global per-CPU state variable sl_state, so that each CPU can independently maintain the state information of the soft deadlock retest phase. Define a global re-examination status variable atomic_t sl_active to indicate whether a soft deadlock re-examination process is currently running in the system.

3. The intelligent detection method for Linux kernel soft deadlock based on threshold re-examination according to claim 1, characterized in that, Step S2, specifically the semantic expansion of the Linux kernel's soft deadlock detection parameters, includes: The semantics of the Linux kernel's soft deadlock panic control configuration item `kernel.watchdog_softlockup_panic` are semantically extended, changing it from a boolean control parameter to a threshold-based re-examination control parameter. The extended configuration is as follows: When the threshold-type re-examination control parameter is configured to the first value, it means that the kernel panic behavior is turned off, the soft deadlock re-examination process is not entered, and the system continues to run after only printing alarm information; When the threshold-type re-examination control parameter is configured to a value greater than the first value, it indicates that after a soft deadlock is detected in the CPU, the soft deadlock re-examination process is entered, and whether to trigger a kernel panic is determined based on whether the number of CPUs with the same type of soft deadlock reaches the configured value of the threshold-type re-examination control parameter.

4. The intelligent detection method for Linux kernel soft deadlock based on threshold re-examination according to claim 1, characterized in that, The threshold-type re-inspection control parameters are determined as follows: During the kernel parameter parsing phase, the configuration values ​​parsed from kernel boot parameters or configuration write operations are subjected to boundary constraints and normalization processing by the softlockup_panic_setup function. The kernel numerical range limiting macro clamp is used to restrict the configuration values ​​to between 0 and the current number of online CPUs, thus obtaining the threshold-type re-examination control parameters. The current number of online CPUs is obtained by the online CPU count acquisition function num_online_cpus.

5. The intelligent detection method for Linux kernel soft deadlock based on threshold re-examination according to claim 1, characterized in that, When the kernel watchdog timer processing path watchdog_timer_fn detects a soft deadlock in the CPU and the threshold-type re-examination control parameter is set to a value that indicates the activation of the soft deadlock re-examination process, step S3 is executed. Step S3 specifically includes: The global re-examination status atomic variable sl_active is used to determine whether the current CPU meets the soft deadlock re-examination triggering condition: when the global re-examination status atomic variable indicates that a CPU is already executing the soft deadlock re-examination process, the re-examination process is not triggered; when the global re-examination status atomic variable indicates that there is no soft deadlock re-examination process, the global re-examination status atomic variable is set to the re-examination running state through atomic operations, so that the current CPU obtains the right to execute the soft deadlock re-examination. After the current CPU obtains the right to perform soft deadlock re-examination, it calls the sampling callback function sl_collect_ipi, which performs running sampling, to complete the current CPU's stack sampling and soft deadlock classification. Then, it calls the kernel interface function smp_call_function_many, which sends function call requests to multiple CPUs, to send a request to the remote online CPU to trigger the remote online CPU to execute the sampling callback function.

6. The intelligent detection method for Linux kernel soft deadlock based on threshold re-examination according to claim 1, characterized in that, In step S4, determining whether each CPU is experiencing a stall in its operation specifically includes: If the task currently running on the CPU is an idle task, then it is determined that the current CPU does not have any suspicion of stalling. If the difference between the current timestamp obtained by the current timestamp acquisition function get_timestamp and the timestamp of the last confirmed running progress of the current CPU obtained by the per-CPU variable access macro per_cpu is less than a preset multiple of the soft deadlock watchdog detection period sample_period, then it is determined that the current CPU does not have any suspicion of stalling. If none of the above conditions are met, then it is determined that the current CPU has stalled.

7. The intelligent detection method for Linux kernel soft deadlock based on threshold re-examination according to claim 1, characterized in that, In step S4, the call stack of the current execution context of the CPU where the execution progress has stalled is collected, and the corresponding soft deadlock type is determined based on the critical path characteristics in the call stack. Specifically, this includes: The stack record members in the current CPU's runtime status record data structure are initialized. The member `trace.nr_entries`, representing the number of recorded stack entries, is set to its initial value. The member `trace.max_entries`, which limits the maximum sampling depth, is set to the preset maximum sampling depth. The member `trace.entries`, which points to the return address storage buffer, is set to point to the return address array. Then, the kernel interface function `save_stack_trace`, which performs call stack backtracking sampling, is called to sample the call chain of the current CPU's execution context. A loop iterating through the call stack entries performs critical path feature matching on the sampling results. Based on the matching results, the corresponding soft deadlock type is determined. When the call stack contains the spinlock-related function `spin_lock`, the soft deadlock type is determined to be a spinlock type; when the call stack contains scheduling-related paths, the soft deadlock type is determined to be a scheduling blocking type; when the call stack contains I / O waiting paths, the soft deadlock type is determined to be an I / O blocking type; when the call stack contains RCU-related functions, the soft deadlock type is determined to be an RCU type; when no preset characteristic function is matched, the soft deadlock type is determined to be an undefined type.

8. The intelligent detection method for Linux kernel soft deadlock based on threshold re-examination according to claim 1, characterized in that, In step S5, obtaining the soft deadlock type of the current CPU includes: reading the soft deadlock type classification result from the running status record data structure corresponding to the current CPU by obtaining the kernel interface macro this_cpu_ptr of the CPU variable instance address on the current CPU, and using the soft deadlock type classification result as the benchmark type for this re-examination statistics and decision-making; The process of counting the number of CPUs with the same soft deadlock type as the current CPU to obtain the number of CPUs with the same soft deadlock includes: defining a count variable sl_count for the number of CPUs with the same soft deadlock, and iterating through all online CPUs using a kernel traversal macro. During the traversal, the kernel interface macro per_cpu_ptr, which obtains the address of the CPU variable corresponding to a specified CPU, is used to obtain the soft deadlock type classification result for each online CPU. If the soft deadlock type of an online CPU is consistent with the baseline type, the value of the count variable for the number of CPUs with the same soft deadlock is incremented.

9. A Linux kernel soft deadlock intelligent detection system based on threshold re-checking, comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to perform the steps of the Linux kernel soft deadlock intelligent detection method based on threshold re-examination as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program / instructions, characterized in that, The computer program / instructions are programmed or configured to execute the steps of the Linux kernel soft deadlock intelligent detection method based on threshold re-examination as described in any one of claims 1 to 8 via a processor.

Images