Kernel data race detection method and device, electronic equipment and storage medium

Abstract

The present application provides a kind of kernel data competition detection method, device, electronic equipment and storage medium, by obtaining the memory access log generated in the running process of target kernel;Potential competition pair is inferred based on the memory access log, and the potential competition pair includes first access event and second access event;The potential competition pair is verified by directional triggering, including: when executing the first access event, the first thread corresponding to the first access event is suspended and monitoring is started in the replay execution of target kernel;If the second thread executes the second access event is monitored within the preset waiting time, it is determined that the potential competition pair is real data competition, the present application is based on "inference-verification" new detection mode, can greatly improve the discovery ability and performance efficiency to complex data competition while ensuring zero false alarm.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a kernel data contention detection method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the widespread adoption of multi-core processor architectures and the increasing complexity of system software, concurrent execution within the operating system kernel has become commonplace. In this environment, data races, as a typical concurrency flaw, are increasingly becoming a serious threat. A data race occurs when two or more concurrent threads access the same shared memory location without proper synchronization, and at least one of these accesses is a write operation. This race condition leads to uncertainty in execution results, potentially causing data corruption, logical errors, system crashes, and even security vulnerabilities, severely threatening the stability and security of the operating system. The complexity and non-determinism of the operating system kernel's concurrent environment pose significant challenges to the detection of data races. On the one hand, static analysis methods can discover potential data race paths by analyzing source code or intermediate representations; however, due to the lack of runtime information, static analysis often produces numerous false positives, making it difficult to accurately pinpoint the true race point. On the other hand, dynamic detection methods utilize runtime monitoring to avoid false positives from static analysis. However, existing dynamic detection technologies still have many limitations. For example, dynamic lock set analysis requires intercepting and recording all variable accesses and lock operations throughout the process, maintaining complex synchronization state metadata, resulting in huge runtime and memory overhead. This severely interferes with the normal scheduling of kernel threads and system behavior, making it difficult to effectively test time-sensitive real-world scenarios. Mainstream dynamic tools (such as random delayed injection) essentially rely on coincidental thread interleaving to trigger contention, which is a passive waiting mechanism. For deep contention with low probability of occurrence and narrow time windows, random sampling is very likely to miss it, resulting in insufficient coverage of complex concurrent vulnerabilities. It can only capture a "snapshot" when the contention happens to occur, making it impossible to actively explore potential contention or to reproduce discovered contention in a controllable and stable manner. This brings great difficulties to the accurate location of vulnerabilities, root cause analysis, and remediation verification, reducing the practical value of the detection results. Summary of the Invention

[0003] This invention provides a kernel data contention detection method, apparatus, electronic device, and storage medium to address the shortcomings of existing kernel data contention detection methods, such as high performance overhead, impact on normal system execution, blind detection process, missed detection of complex contentions, lack of targeted triggering methods, and difficulty in reproducing contentions.

[0004] This invention provides a kernel data contention detection method, comprising: Obtain the memory access logs generated by the target kernel during its runtime; Based on the memory access log, potential contention pairs are inferred, including a first access event and a second access event; The targeted trigger verification of the potential competition pair includes: during the replay execution of the target kernel, when the first access event is executed, pausing the first thread corresponding to the first access event and starting monitoring; if the second thread is detected executing the second access event within a preset waiting time, the potential competition pair is determined to be a real data competition.

[0005] According to the kernel data contention detection method provided by the present invention, obtaining the memory access logs generated by the target kernel during its operation includes: Static taint analysis is performed on the source code of the target kernel to identify all memory access instructions involving cross-thread shared variables; stub functions are inserted at the identified memory access instructions. After instrumenting the target kernel, memory access events are recorded to generate the memory access log, wherein the memory access events include at least: access address, access type, thread identifier, and timestamp.

[0006] According to the kernel data contention detection method provided by the present invention, the recording of memory access events includes: The memory access events collected by the monitoring stub function are buffered using a lock-free circular buffer. The memory access events in the lock-free circular buffer are asynchronously collected and stored by a log processing thread independent of the kernel thread being tested.

[0007] According to the kernel data contention detection method provided by the present invention, the step of inferring potential contention pairs based on the memory access log includes: Based on the timestamp, the memory access events are arranged in chronological order; a sliding window is set up, and each memory access event is used as a reference event to compare the reference event with at least one other memory access event located in the sliding window; If the matching conditions are met, the benchmark event and the other memory access events are inferred to be a potential competing pair.

[0008] According to the kernel data contention detection method provided by the present invention, the matching conditions include: The two events have the same access address; The two events have different thread identifiers; At least one of the two event access types is a write operation.

[0009] According to the kernel data contention detection method provided by the present invention, the step of pausing the first thread corresponding to the first access event and starting monitoring when the first access event is encountered during the replay execution of the target kernel includes: When the code corresponding to the first access event is executed, a time delay of a preset duration is injected into the first thread; During the time delay, a memory observation point is set for the memory address corresponding to the first access event; The memory observation point is used to monitor whether other threads access the memory address.

[0010] According to the kernel data contention detection method provided by the present invention, after determining that the potential contention pair is a real data contention if the second thread is detected executing the second access event within a preset waiting time, the method further includes: If, within the preset waiting time, it is detected that the second thread accesses the same memory address as the first access event, and the thread identifier accessed is different from the thread identifier of the first access event, then the contention context information when the second thread executes the second access event is recorded, and a contention alarm is triggered based on the contention context information.

[0011] The present invention also provides a kernel data contention detection device, comprising: The acquisition module is used to acquire memory access logs generated by the target kernel during its operation. The inference module is used to infer potential contention pairs based on the memory access log, wherein the potential contention pairs include a first access event and a second access event; The verification module is used to perform targeted verification of the potential competition pair, including: during the replay execution of the target kernel, when the first access event is executed, pausing the first thread corresponding to the first access event and starting monitoring; if the second thread is detected to execute the second access event within a preset waiting time, the potential competition pair is determined to be a real data competition.

[0012] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the kernel data contention detection method as described in any of the preceding claims.

[0013] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the kernel data contention detection method described in any of the preceding claims.

[0014] The kernel data contention detection method, apparatus, electronic device, and storage medium provided by this invention acquire memory access logs generated by the target kernel during its operation; infer potential contention pairs based on the memory access logs; and perform targeted trigger verification on the potential contention pairs, including: during the replay execution of the target kernel, when the first access event is executed, pausing the first thread corresponding to the first access event and starting monitoring; if the second thread is detected executing the second access event within a preset waiting time, then the potential contention pair is determined to be a real data contention. This invention is based on a new "inference-verification" detection mode, which can significantly improve the ability to detect complex data contention and performance efficiency while ensuring zero false positives. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 This is one of the flowcharts of the kernel data contention detection method provided in the embodiments of the present invention; Figure 2 This is a schematic diagram of the inference process for competing variable pairs provided in an embodiment of the present invention; Figure 3 This is a flowchart of the competitive variable pair targeted verification provided in an embodiment of the present invention; Figure 4 This is the second flowchart of the kernel data contention detection method provided in the embodiments of the present invention; Figure 5 This is a functional structure diagram of the kernel data contention detection device provided in an embodiment of the present invention; Figure 6 This is a functional structure diagram of the electronic device provided in the embodiments of the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0018] Figure 1 A flowchart of the kernel data contention detection method provided in the embodiments of the present invention is shown below. Figure 1As shown, the kernel data contention detection method provided in this embodiment of the invention includes: Step 101: Obtain the memory access logs generated by the target kernel during its operation; In this embodiment of the invention, global variables, cross-thread shared memory, and function parameters of kernel functions are used as initial taint sources. The function control flow graph is traversed to trace the propagation paths of these tainted variables. All memory access instructions involving tainted variables are marked as potential race points. Subsequently, monitoring code (stub functions) is inserted into the marked race points under the LLVM compilation framework to record key information about variable access events (including variable identifier, memory address, access type, timestamp, and thread ID). After this step, the instrumented executable file or kernel module is output for subsequent dynamic detection.

[0019] Step 102: Infer potential contention pairs based on the memory access log, wherein the potential contention pairs include a first access event and a second access event; In this embodiment of the invention, if there are two memory access events, they are respectively denoted as: and The access addresses (addr) are the same (indicating access to the same variable or memory location) and occur in different threads. If the events occur close enough together (within a preset time window threshold) and at least one of them is a write operation (type includes Write), then this pair of access events is inferred to be a potential data race variable pair.

[0020] For each pair of events that meet the criteria, the execution context information (such as function call stack fragments) at the time of their occurrence is further extracted and recorded for use in the verification phase. Log analysis yields a list of potential competing variable pairs.

[0021] Step 103: Perform targeted trigger verification on the potential competition pair, including: during the replay execution of the target kernel, when the first access event is executed, pause the first thread corresponding to the first access event and start monitoring; if the second thread is detected executing the second access event within a preset waiting time, then determine that the potential competition pair is a real data competition.

[0022] In this embodiment of the invention, the kernel module under test is rerun, and the memory observation point and delayed injection mechanism are used to control thread scheduling by setting up the instrumentation point and running the program. When the program executes to the first variable access in a potential race pair, the observation point is triggered to perform a busy-wait delay on the thread, pausing its continued execution for a preset period of time, while monitoring when another thread executes to the second variable access in the race pair. If another thread is detected to enter the corresponding variable access during the delay wait period (i.e., the two accesses occur within the delay window and the addresses match), it is considered that the condition of two threads accessing the shared variable almost simultaneously has been successfully created, and the data race is triggered and captured. At this time, the system records the specific environment in which the race state occurs and reports the data race vulnerability. If the wait exceeds a set threshold (e.g., 500 milliseconds) and the corresponding access by another thread does not occur, it is considered that the potential race pair is unlikely to form a real race in actual operation, is judged as a false alarm, and the current verification ends. The above verification process is applied to each potential race variable pair one by one. Those that are successfully verified are confirmed to have real data races; those that are not triggered are filtered out from the results.

[0023] Through the targeted verification mechanism, the embodiments of the present invention can ensure that the detection results are free of false alarms and truly transform potential data competition risks into observable competitive behaviors, thereby achieving accurate detection and stable reproduction of data competition vulnerabilities.

[0024] Traditional kernel data contention detection techniques, such as dynamic lock set analysis, require intercepting and recording all variable accesses and lock operations throughout the process, maintaining complex synchronization state metadata. This results in significant runtime and memory overhead, severely interfering with the normal scheduling of kernel threads and system behavior, making it difficult to effectively test time-sensitive real-world scenarios. Mainstream dynamic tools (such as random delayed injection) essentially rely on coincidental thread interleaving to trigger contention, a passive waiting mechanism. For deep contention with low probability of occurrence and narrow time windows, random sampling is prone to missing it, leading to insufficient coverage of complex concurrency vulnerabilities. They can only capture a "snapshot" when contention happens to occur, unable to actively explore potential contention or reproduce discovered contention in a controllable and stable manner. This greatly complicates the accurate location of vulnerabilities, root cause analysis, and remediation verification, reducing the practical value of the detection results.

[0025] The kernel data contention detection method provided in this invention obtains memory access logs generated by the target kernel during its operation; infers potential contention pairs based on the memory access logs; and performs targeted trigger verification on the potential contention pairs, including: during the replay execution of the target kernel, when the first access event is executed, pausing the first thread corresponding to the first access event and starting monitoring; if the second thread is detected executing the second access event within a preset waiting time, then the potential contention pair is determined to be a real data contention. This invention is based on a new "inference-verification" detection mode, which can significantly improve the ability to detect complex data contention and performance efficiency while ensuring zero false positives.

[0026] Based on any of the above embodiments, obtaining the memory access logs generated by the target kernel during operation includes: Step 201: Perform static taint analysis on the source code of the target kernel to identify all memory access instructions involving cross-thread shared variables; insert monitoring stub functions at the identified memory access instructions; Step 202: Run the instrumented target kernel and record memory access events to generate the memory access log, wherein the memory access events include at least: access address, access type, thread identifier and timestamp.

[0027] In this embodiment of the invention, the callback mechanism of the instrumented code continuously monitors the access of each thread to shared variables during operation. Each time a read / write operation of an instrumented variable occurs, a memory access event is recorded in the log structure through the stub function. The log content includes information such as the globally unique variable identifier, the actual memory address, the precise timestamp, the accessing thread identifier, and the access type (read or write).

[0028] Based on any of the above embodiments, the recording of memory access events includes: Step 301: Buffer the memory access events collected by the monitoring stub function using a lock-free circular buffer; Step 302: Collect and store memory access events in the lock-free circular buffer asynchronously through a log processing thread independent of the kernel thread being tested.

[0029] This invention employs kernel loadable module (LKM) technology to dynamically deploy observation points and uses a lock-free circular buffer for efficient log writing. Combined with parallel processing and signal wake-up mechanisms, the impact of monitoring on system performance is minimized. After the test run is complete, a complete memory access log is collected for offline analysis.

[0030] Based on any of the above embodiments, the step of inferring potential contention pairs based on the memory access log includes: Step 401: Based on the timestamp, arrange the memory access events in chronological order; set a sliding window, using each memory access event as a reference event, and compare the reference event with at least one other memory access event located in the sliding window; Step 402: If the matching condition is met, the baseline event and the other memory access events are inferred to be a potential competition pair.

[0031] In the compile-time instrumentation stage, this invention identifies shared variable access points in the kernel code that may have data races through static taint analysis and inserts monitoring stubs at these locations, specifically including: All global variables, cross-thread shared memory regions, and function parameters whose scope extends beyond a single thread are marked as tainted sources, and the propagation of these taints is traced by traversing the control flow graph of kernel functions. When an instruction's operand involves a tainted variable, the variable produced by that instruction is also marked as tainted, and this process is recursively repeated until stability is achieved. Ultimately, memory read / write instructions associated with tainted variables are identified as potential race conditions.

[0032] By leveraging the LLVM compiler infrastructure, stub code is inserted into these instructions, embedding hooks before and after the corresponding memory accesses to collect runtime information. After this stage of processing, the generated kernel module under test already contains monitoring stubs, which can capture critical variable access events at runtime.

[0033] like Figure 2 As shown, this embodiment of the invention loads and executes the instrumented kernel module and collects variable access logs in real time. During execution, multiple threads trigger the stub code to record the access event in the global log whenever they encounter an instrumented variable access instruction. The log recording is efficiently written to memory using a lock-free circular buffer, and the recorded content includes: the accessed variable identifier, the actual memory address, the access type (read / write), the occurrence timestamp (high precision), the thread ID, and brief execution context information. To reduce the impact on system performance, the log collection process utilizes the kernel's asynchronous parallel mechanism, combined with signal interrupt triggering, to download the heavy log processing work to an independent kernel thread. After the kernel module's test run is completed, the method reads and parses the log file in user space, performing inference analysis on all captured variable access events.

[0034] During the inference and analysis process, a sliding window algorithm is used to incrementally scan log event sequences (such as...). Figure 2 As shown in the figure, determine whether there is an access pair that satisfies the data race condition.

[0035] According to the definition of data contention, the matching criteria for determining the matching conditions are address consistency, thread heterogeneity, and temporal proximity. The two events have the same access address; The two events have different thread identifiers; At least one of the two event access types is a write operation.

[0036] In this embodiment of the invention, the access events of any two different threads are searched in the log. If they access the same memory address and at least one is a write operation, and the time interval between the two accesses does not exceed a preset window threshold, it can be inferred that these two accesses constitute a potential race variable pair. For example, in Figure 2 In the log snippet shown, variable accesses X and Y satisfy the above conditions and are therefore extracted as a potential competing variable pair, with the corresponding variable context information recorded. By analyzing the entire log, a list of all potential competing variable pairs is obtained. This inference mechanism can identify variable pairs that may not actually collide in actual operation but pose a competition risk, providing a targeted set for further verification.

[0037] Based on any of the above embodiments, the step of pausing the first thread corresponding to the first access event and starting monitoring when the first access event is encountered during the replay execution of the target kernel includes: When the code corresponding to the first access event is executed, a time delay of a preset duration is injected into the first thread; During the time delay, a memory observation point is set for the memory address corresponding to the first access event; The memory observation point is used to monitor whether other threads access the memory address.

[0038] In this embodiment of the invention, after determining that the potential competition is a real data competition if the second thread is detected executing the second access event within a preset waiting time, the method further includes: If, within the preset waiting time, it is detected that the second thread accesses the same memory address as the first access event, and the thread identifier accessed is different from the thread identifier of the first access event, then the contention context information when the second thread executes the second access event is recorded, and a contention alarm is triggered based on the contention context information.

[0039] In this embodiment of the invention, each potential competing variable obtained in the previous step is verified and tested to confirm whether it will trigger real data competition. The execution flow of the verification phase is as follows: Figure 3 As shown, it specifically includes: The tested kernel module is reloaded and the same test scenario is repeated. This invention sets up a special synchronization mechanism at the two stubs related to the potential contention pair. When thread A reaches the first variable access stub in the contention pair, a memory observation point is started to monitor the variable address, and a delay is injected to pause (busy wait) thread A for a period of time. Subsequently, the system schedules other threads to run. If thread B reaches the second variable access stub in the contention pair during thread A's waiting period, and the accessed address matches the observation point address of thread A, then the two form an actual concurrent access. This momentary conflict is immediately captured, triggering a data contention alarm and recording detailed information. In this way, a contention that might otherwise have been missed is "artificially" triggered through a delayed wait, realizing the reproduction experiment of data contention. If thread B does not access the corresponding variable within the set maximum waiting time (e.g., 500ms), it is considered that the potential contention did not occur in this test execution, and the inference-verification mode judges it as an untriggerable contention pair (suspected false alarm) and excludes it. By repeating the above process, the embodiments of the present invention attempt to verify each candidate competition pair: only those that pass the verification are confirmed as real data competitions, and the rest are filtered out.

[0040] It should be noted that, due to the strict control and synchronization of thread scheduling during the verification phase, the embodiments of the present invention can guarantee zero false alarms (any reported competition is actually triggered and verified), while significantly improving the coverage and reliability of detection for complex competition.

[0041] like Figure 4 As shown, the kernel data contention detection method provided in this embodiment of the invention specifically includes: (1) Obtain the kernel module source code: Obtain the source code of the target operating system kernel or its modules to be tested.

[0042] (2) Obtaining a binary kernel file after instrumentation: Perform static analysis (such as taint analysis) on the source code to identify all critical locations (race risk points) involving cross-thread shared variable access. Then, use the compiler toolchain (such as LLVM) to insert monitoring code (stubs) at these locations and compile to generate an executable kernel binary file with embedded monitoring capabilities; (3) Execute test cases: Load and run the instrumented kernel, and apply concurrent test loads (such as system call sequences and multi-threaded workloads). The purpose is to make the kernel execute in a concurrent environment close to real-world scenarios to stimulate potential competitive behavior; (4) Competitive Variable Pair Collector: During the execution of step (3), the collector, which consists of instrumented code, continues to work. It is responsible for monitoring and recording all marked shared variable access events and generating raw access logs containing information such as memory address, access type, thread ID, and timestamp.

[0043] (5) Targeted verification of competing variables: The logs collected in step (4) are analyzed offline. Through algorithms such as sliding window comparison, access pairs that meet the competition conditions (same address, different threads, writing involved, and time proximity) are selected from all access events to form a list of potential competing pairs to be verified. (6) Delayed injection and secondary execution: Based on the list obtained in step (5), the instrumented kernel is rerun. When the first access point of a potential contested pair is reached, the system will automatically inject a controllable delay to pause the current thread, thereby artificially creating a time window to wait for another thread to reach the second access point of the contested pair; (7) Triggering a data race: Within the delay window created in step (6), if another thread does access the same memory address, a real concurrent access conflict (data race) is actively triggered and captured. The system records the complete context at the time of the trigger (such as the call stack, memory values, etc.) as evidence; (8) Output vulnerability report: The data race instance successfully triggered and captured in step (7), along with its detailed contextual evidence, is automatically generated into a structured vulnerability report. This report can be used directly by developers to locate, understand, and fix vulnerabilities.

[0044] This invention overcomes the limitations of traditional kernel data race detection through an innovative combination of "inference + verification." Without significantly impacting system performance, it can automatically discover and reliably reproduce deep-seated data race vulnerabilities in the operating system kernel, which is of great significance for ensuring kernel concurrency security. The method provided by this invention has a clear flow and strong operability, offering kernel developers and testers a practical and efficient automated means of data race detection.

[0045] This invention provides a kernel data contention detection method, an automatic and efficient operating system kernel data contention detection method, to solve the problems of high performance overhead, blind detection with serious missed detections, and difficulty in triggering and reproducing contention in existing technologies. It utilizes static taint analysis to accurately identify potential shared variables, instrumenting only relevant code locations, significantly reducing the number of instrumentations and the scope of runtime monitoring. Simultaneously, it employs lock-free log buffering, parallel processing, and signal control techniques to optimize the runtime data collection process, reducing performance overhead and ensuring the basic normal operation of the tested system without interfering with thread scheduling. It introduces an "inference-verification" model, inferring potential contention variable pairs by analyzing thread execution trajectories and memory access logs, rather than relying entirely on random scheduling triggers. Compared to traditional blind detection, this invention can uncover many deep-seated data contention risks that are difficult to cover with conventional testing, and then perform targeted verification, greatly expanding the coverage and depth of data contention detection. In the verification phase of detection, it actively controls the thread execution sequence through memory observation points and delayed injection methods, verifying and reproducing each inferred contention point. This targeted triggering mechanism ensures that each potential competitor attempts to reproduce the vulnerability in a controlled environment. Success proves it's a genuine data competition, while failure is automatically classified as a false alarm and filtered out. This mechanism guarantees zero false alarms and ensures that each competitor vulnerability can be reliably reproduced, facilitating debugging and repair by developers.

[0046] The kernel data contention detection method provided by this invention is described below. The kernel data contention detection method described below can be referred to in correspondence with the kernel data contention detection method described above.

[0047] Figure 5 The functional structure diagram of the kernel data contention detection device provided in the embodiments of the present invention is as follows: Figure 5 As shown, the kernel data contention detection device provided in this embodiment of the invention includes: The acquisition module 501 is used to acquire memory access logs generated by the target kernel during its operation. Inference module 502 is used to infer potential contention pairs based on the memory access log; The verification module 503 is used to perform targeted trigger verification of the potential competition pair, including: during the replay execution of the target kernel, when the first access event is executed, pausing the first thread corresponding to the first access event and starting monitoring; if the second thread is detected to execute the second access event within a preset waiting time, the potential competition pair is determined to be a real data competition.

[0048] The kernel data contention detection device provided in this embodiment of the invention acquires memory access logs generated by the target kernel during its operation; infers potential contention pairs based on the memory access logs; and performs targeted trigger verification on the potential contention pairs, including: during the replay execution of the target kernel, when the first access event is executed, pausing the first thread corresponding to the first access event and starting monitoring; if the second thread is detected executing the second access event within a preset waiting time, then the potential contention pair is determined to be a real data contention. This embodiment of the invention is based on a new "inference-verification" detection mode, which can significantly improve the ability to detect complex data contention and performance efficiency while ensuring zero false positives.

[0049] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6 As shown, the electronic device may include a processor 610, a communications interface 620, a memory 630, and a communication bus 640. The processor 610, communications interface 620, and memory 630 communicate with each other via the communication bus 640. The memory 630 contains computer programs, an operating system, and acquired data. The processor 610 can call logical instructions in the memory 630 to execute a kernel data contention detection method. This method includes: acquiring memory access logs generated by the target kernel during its operation; inferring potential contention pairs based on the memory access logs; and performing targeted trigger verification on the potential contention pairs, including: during the replay execution of the target kernel, when the first access event is encountered, pausing the first thread corresponding to the first access event and starting monitoring; if a second thread is detected executing the second access event within a preset waiting time, then the potential contention pair is determined to be a real data contention.

[0050] Furthermore, the logical instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to related technologies, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0051] On the other hand, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the kernel data contention detection method provided by the above methods. The method includes: acquiring memory access logs generated by the target kernel during operation; inferring potential contention pairs based on the memory access logs; and performing targeted trigger verification on the potential contention pairs, including: during the replay execution of the target kernel, when the first access event is executed, pausing the first thread corresponding to the first access event and starting monitoring; if the second thread is detected executing the second access event within a preset waiting time, then determining that the potential contention pair is a real data contention.

[0052] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0053] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of software products. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0054] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A kernel data contention detection method, characterized in that, include: Obtain the memory access logs generated by the target kernel during its runtime; Based on the memory access log, potential contention pairs are inferred, including a first access event and a second access event; Targeted trigger verification of the potential competing pairs includes: during the replay execution of the target kernel, when the first access event is executed, pausing the first thread corresponding to the first access event and starting monitoring; If the second thread is detected executing the second access event within the preset waiting time, the potential competition is determined to be a real data competition.

2. The kernel data contention detection method according to claim 1, characterized in that, The acquisition of memory access logs generated by the target kernel during its operation includes: Static taint analysis is performed on the source code of the target kernel to identify all memory access instructions involving cross-thread shared variables; stub functions are inserted at the identified memory access instructions; After instrumenting the target kernel, memory access events are recorded to generate the memory access log, wherein the memory access events include at least: access address, access type, thread identifier, and timestamp.

3. The kernel data contention detection method according to claim 2, characterized in that, The recorded memory access events include: The memory access events collected by the monitoring stub function are buffered using a lock-free circular buffer. The memory access events in the lock-free circular buffer are asynchronously collected and stored by a log processing thread independent of the kernel thread being tested.

4. The kernel data contention detection method according to claim 1, characterized in that, The inference of potential contention pairs based on the memory access logs includes: Based on the timestamp, the memory access events are arranged in chronological order; a sliding window is set up, and each memory access event is used as a reference event to compare the reference event with at least one other memory access event located in the sliding window; If the matching conditions are met, the benchmark event and the other memory access events are inferred to be a potential competing pair.

5. The kernel data contention detection method according to claim 4, characterized in that, The matching conditions include: The two events have the same access address; The two events have different thread identifiers; At least one of the two event access types is a write operation.

6. The kernel data contention detection method according to claim 1, characterized in that, In the replay execution of the target kernel, when the first access event is encountered, the first thread corresponding to the first access event is paused and monitoring is started, including: When the code corresponding to the first access event is executed, a time delay of a preset duration is injected into the first thread; During the time delay, a memory observation point is set for the memory address corresponding to the first access event; The memory observation point is used to monitor whether other threads access the memory address.

7. The kernel data contention detection method according to claim 1, characterized in that, If the second thread is detected executing the second access event within a preset waiting time, and the potential competition is determined to be a real data competition, the method further includes: If, within the preset waiting time, it is detected that the second thread accesses the same memory address as the first access event, and the thread identifier accessed is different from the thread identifier of the first access event, then the contention context information when the second thread executes the second access event is recorded, and a contention alarm is triggered based on the contention context information.

8. A kernel data contention detection device, characterized in that, include: The acquisition module is used to acquire memory access logs generated by the target kernel during its operation. The inference module is used to infer potential contention pairs based on the memory access log, wherein the potential contention pairs include a first access event and a second access event; The verification module is used to perform targeted verification of the potential competing pairs, including: during the replay execution of the target kernel, when the first access event is executed, pausing the first thread corresponding to the first access event and starting monitoring; If the second thread is detected executing the second access event within the preset waiting time, the potential competition is determined to be a real data competition.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the kernel data contention detection method as described in any one of claims 1 to 7.

10. A non-transitory readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the kernel data contention detection method as described in any one of claims 1 to 7.

Images