CN108959085B - Method and system for detecting sleep error of kernel module in atomic context - Google Patents
Method and system for detecting sleep error of kernel module in atomic context Download PDFInfo
- Publication number
- CN108959085B CN108959085B CN201810711766.9A CN201810711766A CN108959085B CN 108959085 B CN108959085 B CN 108959085B CN 201810711766 A CN201810711766 A CN 201810711766A CN 108959085 B CN108959085 B CN 108959085B
- Authority
- CN
- China
- Prior art keywords
- function
- code
- candidate
- atomic context
- intermediate code
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/366—Software debugging using diagnostics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3628—Software debugging of optimised code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides a method and a system for detecting a sleep error of a kernel module in an atomic context, wherein the method comprises the following steps: compiling a source code of a kernel module to be detected to obtain an intermediate code of the kernel module to be detected; obtaining an atomic context used by the kernel module to be detected, performing static analysis on the intermediate code, obtaining functions called in the atomic context in the intermediate code, and taking each function called by the atomic context as a candidate function; and reporting that the calling of each candidate function in the atomic context has a sleep error if judging that the candidate function calls a preset sleep function according to the call graph of each candidate function in the kernel code of the operating system. The invention automatically detects the dormancy error of the kernel module in the atomic context, improves the detection efficiency and correctness, and thereby enhances the reliability of the kernel module.
Description
Technical Field
The invention belongs to the technical field of computer operating systems and software testing, and particularly relates to a method and a system for detecting sleep errors of a kernel module in an atomic context.
Background
The components in modern operating systems are mostly in the form of kernel modules, including drivers, file systems, network managers, and the like. To improve performance, kernel modules can often execute concurrently and can respond quickly to hardware interrupts using interrupt handling code. In both cases, to protect shared data from competing accesses, the kernel module often protects the data using an atomic context.
An atomic context is a special kernel execution state, which is embodied in two execution cases: a spin lock has been acquired and executed in the interrupt handler. In an atomic context, a thread of a kernel module is executed exclusively by one processor core until execution of the atomic context is complete. During this time, other threads in the operating system cannot use the processor core, but can only wait for the processor core to be unoccupied or execute using other processor cores. If a kernel module sleeps in an atomic context, i.e., relinquishes the current processor core, it may happen that the processor core is occupied and cannot wake up the sleeping thread, thereby causing a system deadlock. However, due to the uncertainty of concurrent execution of the operating system, this deadlock condition does not always occur at real runtime and is therefore difficult to find at runtime. Therefore, there is a need for efficient detection of sleep errors of a kernel module in an atomic context.
To detect such errors, developers often need to manually read the kernel module and the operating system kernel code and then check each function call case by case based on an understanding of the code. Due to the reasons of large code amount, complex code logic, large number of function calling layers and the like of the kernel module, it is difficult to efficiently and accurately find out all operations of the kernel module in the atomic context. In addition, determining whether an operation in a kernel module can be hibernated often requires a relatively rich kernel development experience. In view of the above two points, the method for manually detecting such errors is time-consuming, labor-consuming and prone to problems.
Therefore, designing a good method for automatically detecting the sleep error of the kernel module in the atomic context becomes an urgent problem to be solved in the development and testing of the operating system.
Disclosure of Invention
In order to overcome the problems that the existing method for detecting the sleep error of the kernel module in the atomic context is time-consuming and labor-consuming and is easy to generate errors or at least partially solve the problems, the invention provides a method and a system for detecting the sleep error of the kernel module in the atomic context.
According to a first aspect of the present invention, there is provided a method for detecting a sleep error of a kernel module in an atomic context, comprising:
compiling a source code of a kernel module to be detected to obtain an intermediate code of the kernel module to be detected;
obtaining an atomic context used by the kernel module to be detected, performing static analysis on the intermediate code, obtaining functions called in the atomic context in the intermediate code, and taking each function called by the atomic context as a candidate function;
and reporting that the calling of each candidate function in the atomic context has a sleep error if judging that the candidate function calls a preset sleep function according to the call graph of each candidate function in the kernel code of the operating system.
According to a second aspect of the present invention there is provided a system for detecting a sleep error of a kernel module in an atomic context, comprising:
the compiling module is used for compiling the source code of the kernel module to be detected and acquiring the intermediate code of the kernel module to be detected;
the analysis module is used for acquiring the atomic context used by the kernel module to be detected, performing static analysis on the intermediate code, acquiring functions called in the atomic context in the intermediate code, and taking each function called by the atomic context as a candidate function;
and the checking module is used for reporting that the calling of each candidate function in the atomic context has a sleep error when judging that the candidate function calls a preset sleep function according to the call graph of each candidate function in the kernel code of the operating system.
The invention provides a method and a system for detecting dormancy errors of a kernel module in an atomic context, wherein the method can accurately and efficiently find out a function called in the atomic context from an intermediate code by performing static analysis on the intermediate code of the kernel module to be detected; the method uses the function call graph to check the function called by the atomic context, and can accurately judge whether the function called by the atomic context can be dormant, thereby automatically detecting the dormancy error of the kernel module in the atomic context, improving the detection efficiency and correctness, and enhancing the reliability of the kernel module.
Drawings
Fig. 1 is a schematic overall flowchart of a method for detecting a sleep error of a kernel module in an atomic context according to an embodiment of the present invention;
fig. 2 is a schematic flow chart of adaptive flow sensitivity analysis in a method for detecting a sleep error of a kernel module in an atomic context according to an embodiment of the present invention;
fig. 3 is a schematic overall structure diagram of a system for detecting a sleep error of a kernel module in an atomic context according to an embodiment of the present invention;
fig. 4 is a schematic view of an overall structure of an electronic device according to an embodiment of the present invention.
Detailed Description
The following detailed description of embodiments of the present invention is provided in connection with the accompanying drawings and examples. The following examples are intended to illustrate the invention but are not intended to limit the scope of the invention.
Fig. 1 is a schematic overall flow chart of a method for detecting a sleep error of a kernel module in an atomic context, where the method includes: s101, compiling a source code of a kernel module to be detected to obtain an intermediate code of the kernel module to be detected;
the kernel module to be detected is a kernel module which needs to carry out sleep error detection. The source code of the kernel module to be detected is usually written by the C language, and the syntax of the C language is flexible and changeable, so that it is difficult to directly analyze the program. Therefore, the embodiment compiles the source code of the kernel module to be detected, obtains the intermediate code capable of directly performing program analysis, and facilitates subsequent static analysis.
S102, obtaining an atomic context used by a kernel module to be detected, performing static analysis on the intermediate code, obtaining functions called in the atomic context in the intermediate code, and taking each function called by the atomic context as a candidate function;
the atomic context is a special kernel execution state, and is embodied in two execution cases: a spin lock has been acquired and executed in the interrupt handler. The static analysis of the intermediate code refers to a code analysis technology which scans the intermediate code through the technologies of lexical analysis, syntactic analysis, control flow, data flow analysis and the like and verifies whether the code meets the indexes of normalization, safety, reliability, maintainability and the like in a mode of not running the code. And acquiring the atomic context used by the kernel module to be detected. And performing static analysis on the intermediate code, acquiring all functions called in the atomic context in the intermediate code, and taking the functions as candidate functions.
S103, if judging that the obtained candidate function calls the preset sleep function according to the call graph of each candidate function in the kernel code of the operating system, reporting that sleep errors exist in the calling of each candidate function in the atomic context.
And the call graph of each candidate function in the kernel code of the operating system is the call relation between each candidate function and other functions. The preset sleep function is a preset function which can cause sleep. And checking the call graph of each candidate function in the kernel code of the operating system through static analysis, and judging whether each candidate function calls a preset dormant function or not. If each candidate function calls the preset dormancy function, the fact that the candidate function can be dormant is known, and the candidate function is called in the atomic context, namely the candidate function is called in the atomic context and has a dormancy error. The present embodiment needs to provide a source code of a kernel module to be tested, a kernel code of an operating system, and a preset sleep function.
According to the embodiment, the function called in the atomic context can be accurately and efficiently found out from the intermediate code by performing static analysis on the intermediate code of the kernel module to be detected, and then the function called in the atomic context is checked by using the function call graph, so that whether the function called in the atomic context can be dormant or not can be accurately judged, the dormancy error of the kernel module in the atomic context is automatically detected, the detection efficiency and the detection accuracy are improved, and the reliability of the kernel module is enhanced.
On the basis of the foregoing embodiment, in this embodiment, compiling the source code of the kernel module to be detected to obtain the intermediate code of the kernel module to be detected includes the specific steps of: compiling each source code file of the kernel module to be detected respectively based on a front-end compiler in the LLVM compiler architecture to generate an intermediate code file of each source code file; and merging the intermediate code files into one intermediate code file based on a code merger in the LLVM compiler architecture, and acquiring the intermediate code from the merged intermediate code file.
In particular, the core module is usually compiled directly using a GCC compiler, but the GCC compiler cannot generate intermediate code that is convenient for program analysis. The LLVM compiler architecture can fully support C language compilation and can generate intermediate code that facilitates program analysis. Therefore, the present embodiment uses the LLVM compiler architecture to compile the source code of the kernel module to be detected. Firstly, a front-end compiler Clang provided by an LLVM compiler architecture is used for compiling each source code file of a kernel module to be detected respectively to generate a corresponding intermediate code file. Secondly, a code merger LLVM-link provided by the LLVM compiler architecture is used for merging all the intermediate code files into a total intermediate code file, and the intermediate code is acquired from the total intermediate code file, so that the later static analysis is facilitated.
On the basis of the above embodiment, in this embodiment, the static analysis is performed on the intermediate code to obtain the function called in the atomic context in the intermediate code, and the specific steps include: and carrying out flow sensitivity analysis on the function of the operation which changes the atomic context in the intermediate code, carrying out flow insensitivity analysis on the function of the operation which does not change the atomic context in the intermediate code, and obtaining the function called in the atomic context in the intermediate code.
Specifically, the present embodiment performs adaptive stream-sensitive analysis on intermediate codes. Specifically, flow sensitivity analysis is carried out on a function which contains the operation of changing the atomic context in the intermediate code, all possible code paths in the function are traversed, flow insensitivity analysis is carried out on a function which does not contain the operation of changing the atomic context, and only all codes in the function are traversed. In the embodiment, the adaptive stream sensitivity analysis is performed on the intermediate code, the accuracy of the stream sensitivity analysis and the high efficiency of the stream insensitivity analysis are both considered, and the two analysis technologies are reasonably selected and used according to the logic of the intermediate code, so that the intermediate code of the kernel module to be tested can be accurately and efficiently analyzed, and a function which is possibly called in an atomic context in the intermediate code is obtained.
On the basis of the above embodiments, the functions of the operation for changing the atomic context in this embodiment include a spin lock acquisition function and a spin lock release function; correspondingly, the intermediate code is statically analyzed, and the function called in the atomic context in the intermediate code is obtained, and the specific steps comprise: acquiring function call and interrupt processing functions acquired by all spin locks in the intermediate code, and acquiring a code basic block where the function call acquired by each spin lock is located and an entry code basic block of each interrupt processing function;
wherein the function call for spin lock acquisition is used to call a spin lock acquisition function. The spin lock acquisition function is a function for acquiring a spin lock, and the interrupt processing function is a function for performing interrupt processing. And when the intermediate code is subjected to static analysis, taking the entrance of the interrupt processing function and the function calling position acquired by the spin lock as the entrance of the static analysis.
Performing static analysis on function calls acquired by respective spin locks according to the code basic block, the spin lock stack and the interrupt state, and performing static analysis on each interrupt processing function according to the entry code basic block, the spin lock stack and the interrupt state to acquire a function called by an atomic context; when the function call acquired by each spin lock is subjected to static analysis, the interrupt state is false; the interrupt status is true when each interrupt handling function is statically analyzed.
Specifically, the static analysis in this embodiment is adaptive flow-sensitive analysis. Interrupt states and spin lock stacks need to be maintained during static analysis of intermediate code. The spin lock stack is used for identifying whether spin lock acquisition and release operations can occur. When the interrupt handling function is analyzed, the interrupt status is set to true. When analyzing the non-interrupt handling function, the interrupt status is set to false. And when the function call acquired or released by the spin lock is acquired in the analysis process, performing corresponding stack entering or stack exiting operation of the spin lock stack. When the interrupt status is true or the spin lock stack is not empty, it indicates that the currently analyzed code is in the atomic context.
Pseudo code for the adaptive flow sensitivity analysis algorithm is as follows:
wherein, the number in front of each line code is a line number. The algorithm maintains three pieces of information during the analysis: an interrupt state intr _ flag, a spin lock stack lock _ stack, and code path information path _ info. The algorithm uses two sub-algorithms HanCall and HanBlock, wherein HanCall is used for processing function calls, and HanBlock is used for processing basic blocks of codes. The adaptive flow sensitivity analysis algorithm mainly comprises three steps:
(1) find out the set lock _ call _ set of function call obtained by spin lock and the set intr _ func _ set of interrupt handling function.
(2) Each function call lock _ call in lock _ call _ set is processed. Firstly, obtaining a code basic block where the function call is located, then emptying a spin lock stack lock _ stack and analyzed code path information path _ info, and setting an interrupt state intr _ flag to be false. And processing the code basic block by utilizing a sub-algorithm HanBlock, and introducing a lock _ stack, an intr _ flag and a path _ info as parameters.
(3) Each interrupt handling function intr _ func in intr _ func _ set is processed. Firstly, an entry code basic block entry _ block of the function is obtained, then a spin lock stack block _ stack and analyzed code path information path _ info are cleared, and an interrupt state intr _ flag is set to be true. And processing an entry code basic block entry _ block by using a sub-algorithm HanBlock, and introducing a block _ stack, an intr _ flag and a path _ info as parameters.
On the basis of the above embodiment, in this embodiment, static analysis is performed on function calls obtained by respective spin locks according to the located code basic block, spin lock stack, and interrupt state, and the specific steps include: if each function in the code basic block calls a spin lock acquisition function, stacking the spin lock stack; if each function in the code basic block calls a spin lock release function, popping the spin lock stack; if the spin lock stack is not in a null value or the interrupt state is true, the function called by each function call in the code basic block is called by the atomic context.
Specifically, the following is the pseudo code of the sub-algorithm HanBlock:
wherein, the number in front of each line code is a line number. The sub-algorithm is used for processing a code basic block myblock, and taking a spin lock stack lock _ stack, an interrupt state intr _ flag and analyzed code path information path _ info as input parameters. Firstly, the sub-algorithm checks whether myblock already exists in the path _ info, if yes, the sub-algorithm returns directly, and therefore repeated analysis is avoided; otherwise myblock is added to path _ info. Then, each function call func _ call in myblock is processed using the sub-algorithm. If the func _ call calls the spin lock acquisition function, performing stacking operation on a spin lock stack lock _ stack; if the func _ call calls the spin lock release function, performing pop operation on the spin lock stack lock _ stack; if func _ call is not a spin lock related function of the above two classes, the sub-algorithm HanCall is used to process func _ call. And then, the sub-algorithm judges whether the spin lock stack lock _ stack is empty and whether the interrupt state intr _ flag is false, if so, the current analyzed code is not in the atomic context, and the current analyzed code is directly returned. Finally, the sub-algorithm recursively uses HanBlock to process each subsequent code basic block of myblock.
The pseudo code for the sub-algorithm HanCall is as follows:
wherein, the number in front of each line code is a line number. The sub-algorithm is used for processing the function call mycall and taking the spin lock stack lock _ stack, the interrupt state intr _ flag and the searched code path information path _ info as input parameters. Firstly, the sub-algorithm judges whether the spin lock stack lock _ stack is empty and whether the interrupt state intr _ flag is false, if so, the currently analyzed code is proved not to be in the atomic context, and the currently analyzed code is directly returned. Then, the sub-algorithm obtains a function myfunc called by the mycall, and the function is taken as a candidate function to be recorded. Then, the sub-algorithm processes the function myfunc and judges whether to use the flow sensitive analysis or the flow insensitive analysis according to the function calling condition contained in the function myfunc. If the function myfunc contains a function call to acquire/release a spin lock, then it is proven that the function myfunc contains an operation that changes the atomic context, and therefore a flow sensitive analysis needs to be performed. Specifically, an entry code basic block entry _ block of the function myfunc is obtained and then analyzed using the sub-algorithm HanBlock. Otherwise, a flow insensitive analysis is performed, i.e. each function call in myfunc is processed recursively using the sub-algorithm HanCall.
For example, an example section of source code for a kernel module to be tested is shown below:
wherein, the number in front of each line code is a line number. The source code of the kernel module to be detected comprises functions MyFunc, FuncA and FuncB, wherein MyFunc calls FuncA and FuncB, MyFunc and FuncB call a spin lock acquisition function spin _ lock and a spin lock release function spin _ unlock, and flow sensitivity analysis needs to be carried out on MyFunc and FuncB. FuncA does not call spin lock related functions, so a flow insensitive analysis is required for FuncA. Fig. 2 shows the static analysis process with the MyFunc function as an entry and is represented in the form of a function call path, where the numbers in the nodes represent the corresponding code line numbers. In fig. 2, the node in the dashed box 1 is the function MyFunc, the node in the dashed box 2 is the function FuncA, and the node in the dashed box 3 is the function FuncB. The function MyFunc calls a spin lock acquisition function spin _ lock on the 5 th line, so that the stack pushing operation of the spin lock stack is required; the function FuncB calls a spin lock release function spin _ unlock in the 24 th line, so that a pop operation needs to be performed on the spin lock stack, and since the spin lock stack is empty at this time, the return is performed directly, and a subsequent path in the FuncB function is not analyzed any more. Finally, according to the adaptive flow sensitivity analysis algorithm, when the function MyFunc is taken as an inlet for analysis, only two useful function call paths are needed to be analyzed, such as a solid line with an arrow in FIG. 2, and other two useless function call paths are omitted, such as a dotted line with an arrow in FIG. 2, so that useless path search is reduced, and the algorithm analysis efficiency is effectively improved.
The adaptive flow sensitivity analysis algorithm in the embodiment considers both the accuracy of flow sensitivity analysis and the high efficiency of flow insensitivity analysis, so that the code of the tested kernel module can be accurately and efficiently analyzed.
On the basis of the foregoing embodiment, in this embodiment, the step of performing static analysis on the function call acquired by each spin lock according to the located code basic block, spin lock stack, and interrupt state further includes: and if the function called by each function call in the code basic block is not a spin lock acquisition function or a spin lock release function, performing static analysis on each function call in the function called by each function call in the code basic block.
On the basis of the foregoing embodiment, in this embodiment, the step of performing static analysis on the function call acquired by each spin lock according to the located code basic block, spin lock stack, and interrupt state further includes: if the code basic block exists in the analyzed code path information, directly returning; and if the located code basic block does not exist in the analyzed code path information, adding the path information of the located code basic block into the analyzed code path information.
On the basis of the foregoing embodiments, in this embodiment, when it is determined that the candidate function calls the preset hibernation function according to the call graph of each candidate function in the kernel code of the operating system, the specific step of reporting that the call of each candidate function in the atomic context has a hibernation error includes: if each candidate function is a preset sleep function, reporting that sleep errors exist in the calling of each candidate function in the atomic context; if each candidate function exists in the function cache table, reporting whether the calling of each candidate function in the atomic context has a sleep error or not according to the mark of each candidate function in the function cache table; and if the candidate functions do not exist in the function cache table, performing static analysis on the functions called by the function calls in the candidate functions, and adding the candidate functions, the functions called by the function calls in the candidate functions and the analysis result into the function cache table.
Specifically, the pseudo code of the functional sleep check algorithm is as follows:
wherein, the number in front of each line code is a line number. The algorithm uses a flow insensitive analysis to check whether a given function myfunc will go to sleep based on the operating system kernel code, and uses a function cache table to reduce duplicate checks. First, the algorithm determines if myfunc is a basic function that can go to sleep, and if so, returns true. The algorithm will then check if myfunc is in the function cache table, and if so, return true or false depending on the tag result in the cache table. Then, the algorithm circularly checks the call of each function in the myfunc, obtains the called function func, and recursively checks the func by using the CheckFunc. If the return value is true, indicating that the function func can go to sleep, then myfunc is added to the function cache table and marked that it can go to sleep, and true is returned indicating that myfunc can go to sleep. Finally, if there is no return in the loop, meaning myfunc is not going to sleep, add myfunc to the function cache table and mark it as not going to sleep, and return false.
In the embodiment, flow insensitivity analysis is performed based on the function dormancy check algorithm, whether the function can be dormant can be judged quickly and accurately, and repeated check is reduced by using the function cache table, so that the check efficiency is effectively improved.
On the basis of the above embodiments, in this embodiment, after reporting that there is a sleep error in the call of each candidate function in the atomic context, the method further includes generating an error report according to the call path of the candidate function, the name of the source code file in which the candidate function is located, and the line number of the candidate function in the source code file.
The generated error report comprises the call path of the candidate function, the name of the source code file where the candidate function is located and the line number of the candidate function in the source code file, so that a developer and a tester can read and check the error report conveniently.
In another embodiment of the present invention, a system for detecting a sleep error of a kernel module in an atomic context is provided, and fig. 3 is a schematic overall structure diagram of the system for detecting a sleep error of a kernel module in an atomic context according to an embodiment of the present invention, where the system includes a compiling module 301, an analyzing module 302, and a checking module 303; wherein:
the compiling module 301 is configured to compile a source code of a kernel module to be detected, and acquire an intermediate code of the kernel module to be detected; the analysis module 302 is configured to obtain an atomic context used by the kernel module to be detected, perform static analysis on the intermediate code, obtain functions called in the atomic context in the intermediate code, and use each function called in the atomic context as a candidate function; the checking module 303 is configured to report that a sleep error exists in the call of each candidate function in the atomic context when it is determined that the candidate function calls a preset sleep function according to the call graph of each candidate function in the kernel code of the operating system.
On the basis of the foregoing embodiment, the compiling module in this embodiment is specifically configured to: compiling each source code file of the kernel module to be detected based on a front-end compiler in an LLVM compiler framework to generate an intermediate code file of each source code file; and merging the intermediate code files into one intermediate code file based on a code merger in the LLVM compiler architecture, and acquiring the intermediate code from the merged intermediate code file.
On the basis of the foregoing embodiment, the analysis module in this embodiment is specifically configured to: and carrying out flow sensitivity analysis on a function of the operation which changes the atomic context in the intermediate code, carrying out flow insensitivity analysis on a function of the operation which does not change the atomic context in the intermediate code, and obtaining the function called in the atomic context in the intermediate code.
On the basis of the above embodiments, the functions of the operation for changing the atomic context in this embodiment include a spin lock acquisition function and a spin lock release function; correspondingly, the analysis module is specifically configured to: acquiring function calls and interrupt processing functions acquired by all spin locks in the intermediate code, and acquiring a code basic block where the function calls acquired by the spin locks are located and an entry code basic block of each interrupt processing function; performing static analysis on function calls acquired by the spin locks according to the code basic block, the spin lock stack and the interrupt state, and performing static analysis on the interrupt processing functions according to the entry code basic block, the spin lock stack and the interrupt state to acquire functions called by the atomic context; when the function call acquired by each spin lock is subjected to static analysis, the interrupt state is true; when each interrupt handling function is statically analyzed, the interrupt status is false.
On the basis of the foregoing embodiment, the analysis module in this embodiment is further configured to: if each function in the code basic block calls the called spin lock acquisition function, stacking the spin lock stack; if each function in the code basic block calls the called spin lock release function, the spin lock stack is popped; and if the spin lock stack is not a null value or the interrupt state is true, acquiring that the function called by each function call in the code basic block is called by the atomic context.
On the basis of the foregoing embodiment, the analysis module in this embodiment is further configured to: and if the function called by each function call in the code basic block is not the spin lock acquisition function or the spin lock release function, performing static analysis on each function call in the function called by each function call in the code basic block.
On the basis of the foregoing embodiment, the analysis module in this embodiment is further configured to: if the code basic block exists in the analyzed code path information, directly returning; and if the located code basic block does not exist in the analyzed code path information, adding the path information of the located code basic block into the analyzed code path information.
On the basis of the foregoing embodiments, in this embodiment, the checking module is specifically configured to: if each candidate function used for judging the sleep error is a preset sleep function, reporting that the sleep error exists in the calling of each candidate function in the atomic context; if each candidate function exists in a function cache table, reporting whether a sleep error exists in the calling of each candidate function in the atomic context according to the mark of each candidate function in the function cache table; and if the candidate functions do not exist in the function cache table, taking the function called by the function call in the candidate functions as the candidate function for judging the sleep error next time.
On the basis of the foregoing embodiments, in this embodiment, the method further includes a generating module, configured to generate an error report according to the call path of the candidate function, the name of the source code file in which the candidate function is located, and the line number of the candidate function in the source code file.
According to the embodiment, the function called in the atomic context can be accurately and efficiently found out from the intermediate code by performing static analysis on the intermediate code of the kernel module to be detected, and then the function called in the atomic context is checked by using the function call graph, so that whether the function called in the atomic context can be dormant or not can be accurately judged, the dormancy error of the kernel module in the atomic context is automatically detected, the detection efficiency and the detection accuracy are improved, and the reliability of the kernel module is enhanced.
The embodiment provides an electronic device, and fig. 4 is a schematic view of an overall structure of the electronic device according to the embodiment of the present invention, where the electronic device includes: at least one processor 401, at least one memory 402, and a bus 403; wherein the content of the first and second substances,
the processor 401 and the memory 402 communicate with each other via a bus 403;
the memory 402 stores program instructions executable by the processor 401, and the processor calls the program instructions to perform the methods provided by the above method embodiments, for example, the methods include: compiling a source code of a kernel module to be detected to obtain an intermediate code of the kernel module to be detected; obtaining an atomic context used by a kernel module to be detected, performing static analysis on the intermediate code, obtaining functions called in the atomic context in the intermediate code, and taking each function called by the atomic context as a candidate function; and if judging that the obtained candidate function calls the preset dormant function according to the call graph of each candidate function in the kernel code of the operating system, reporting that the calling of each candidate function in the atomic context has a dormant error.
The present embodiments provide a non-transitory computer-readable storage medium storing computer instructions that cause a computer to perform the methods provided by the above method embodiments, for example, including: compiling a source code of a kernel module to be detected to obtain an intermediate code of the kernel module to be detected; obtaining an atomic context used by a kernel module to be detected, performing static analysis on the intermediate code, obtaining functions called in the atomic context in the intermediate code, and taking each function called by the atomic context as a candidate function; and reporting that the calling of each candidate function in the atomic context has a sleep error if judging that the obtained candidate function calls the preset sleep function according to the calling graph of each candidate function in the kernel code of the operating system.
Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.
The above-described embodiments of the electronic device are merely illustrative, and units illustrated as separate components may or may not be physically separate, and components displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods of the various embodiments or some parts of the embodiments.
Finally, the method of the present application is only a preferred embodiment and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (9)
1. A method for detecting a sleep error of a kernel module in an atomic context, comprising:
compiling a source code of a kernel module to be detected to obtain an intermediate code of the kernel module to be detected;
obtaining an atomic context used by the kernel module to be detected, performing static analysis on the intermediate code, obtaining functions called in the atomic context in the intermediate code, and taking each function called by the atomic context as a candidate function;
if judging that the candidate function calls a preset dormant function according to the call graph of each candidate function in the kernel code of the operating system, reporting that the calling of each candidate function in the atomic context has a dormant error;
performing static analysis on the intermediate code to obtain a function called in the atomic context in the intermediate code, wherein the specific steps include:
and carrying out flow sensitivity analysis on a function of the operation which changes the atomic context in the intermediate code, carrying out flow insensitivity analysis on a function of the operation which does not change the atomic context in the intermediate code, and obtaining the function called in the atomic context in the intermediate code.
2. The method according to claim 1, wherein compiling a source code of a kernel module to be detected to obtain an intermediate code of the kernel module to be detected comprises the specific steps of:
compiling each source code file of the kernel module to be detected based on a front-end compiler in an LLVM compiler framework to generate an intermediate code file of each source code file;
and merging the intermediate code files into one intermediate code file based on a code merger in the LLVM compiler architecture, and acquiring the intermediate code from the merged intermediate code file.
3. The method of claim 1, wherein the function of the operation that changes the atomic context comprises a spin lock acquire function and a spin lock release function;
correspondingly, the static analysis is carried out on the intermediate code to obtain the function called in the atomic context in the intermediate code, and the specific steps comprise:
acquiring function calls and interrupt processing functions acquired by all spin locks in the intermediate code, and acquiring a code basic block where the function calls acquired by the spin locks are located and an entry code basic block of each interrupt processing function;
performing static analysis on function calls acquired by the spin locks according to the code basic block, the spin lock stack and the interrupt state, and performing static analysis on the interrupt processing functions according to the entry code basic block, the spin lock stack and the interrupt state to acquire functions called by the atomic context;
when the function call acquired by each spin lock is subjected to static analysis, the interrupt state is false;
when each interrupt handling function is statically analyzed, the interrupt status is true.
4. The method according to claim 3, wherein the static analysis of the function call obtained by each spin lock is performed according to the located code basic block, spin lock stack and the interrupt state, and the specific steps include:
if each function in the code basic block calls a spin lock acquisition function, performing stack-entering operation on a spin lock stack;
if each function in the code basic block calls a spin lock release function, performing pop operation on the spin lock stack;
and if the spin lock stack is not a null value or the interrupt state is true, acquiring that the function called by each function call in the code basic block is called by the atomic context.
5. The method according to claim 4, wherein the step of performing static analysis on the function call obtained by each spin lock according to the located code basic block, spin lock stack and the interrupt status further comprises:
and if the function called by each function call in the code basic block is not the spin lock acquisition function or the spin lock release function, performing static analysis on each function call in the function called by each function call in the code basic block.
6. The method according to claim 3, wherein the step of performing static analysis on the function call obtained by each spin lock according to the located code basic block, spin lock stack and the interrupt status further comprises:
if the code basic block exists in the analyzed code path information, directly returning;
and if the located code basic block does not exist in the analyzed code path information, adding the path information of the located code basic block into the analyzed code path information.
7. The method according to any one of claims 1 to 6, wherein when it is determined that the candidate function calls a preset sleep function according to a call graph of each candidate function in an operating system kernel code, reporting that there is a sleep error in the call of each candidate function in the atomic context, the specific steps include:
if each candidate function is a preset dormant function, reporting that a dormant error exists in the calling of each candidate function in the atomic context;
if each candidate function exists in a function cache table, reporting whether a sleep error exists in the calling of each candidate function in the atomic context according to the mark of each candidate function in the function cache table;
and if the candidate functions do not exist in the function cache table, performing static analysis on the function called by each function call in the candidate functions, and adding the candidate functions, the function called by each function call in the candidate functions and the analysis result into the function cache table.
8. The method of any of claims 1-6, further comprising, after reporting a sleep error for a call of each of the candidate functions in the atomic context:
and generating an error report according to the calling path of the candidate function, the name of the source code file where the candidate function is located and the line number of the candidate function in the source code file.
9. A system for detecting a sleep error of a kernel module in an atomic context, comprising:
the compiling module is used for compiling the source code of the kernel module to be detected and acquiring the intermediate code of the kernel module to be detected;
the analysis module is used for acquiring the atomic context used by the kernel module to be detected, performing static analysis on the intermediate code, acquiring functions called in the atomic context in the intermediate code, and taking each function called by the atomic context as a candidate function;
the checking module is used for reporting that a sleep error exists in the calling of each candidate function in the atomic context when judging that the candidate function calls a preset sleep function according to the call graph of each candidate function in the kernel code of the operating system;
wherein, the analysis module is specifically configured to: and carrying out flow sensitivity analysis on a function of the operation which changes the atomic context in the intermediate code, carrying out flow insensitivity analysis on a function of the operation which does not change the atomic context in the intermediate code, and obtaining the function called in the atomic context in the intermediate code.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810711766.9A CN108959085B (en) | 2018-06-25 | 2018-06-25 | Method and system for detecting sleep error of kernel module in atomic context |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810711766.9A CN108959085B (en) | 2018-06-25 | 2018-06-25 | Method and system for detecting sleep error of kernel module in atomic context |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108959085A CN108959085A (en) | 2018-12-07 |
| CN108959085B true CN108959085B (en) | 2020-09-01 |
Family
ID=64484902
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810711766.9A Active CN108959085B (en) | 2018-06-25 | 2018-06-25 | Method and system for detecting sleep error of kernel module in atomic context |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108959085B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112527302B (en) * | 2019-09-19 | 2024-03-01 | 北京字节跳动网络技术有限公司 | Error detection method and device, terminal and storage medium |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101403979A (en) * | 2008-10-27 | 2009-04-08 | 成都市华为赛门铁克科技有限公司 | Locking method for self-spinning lock and computer system |
| CN102222015A (en) * | 2010-04-13 | 2011-10-19 | 三星电子（中国）研发中心 | System and method for detecting deadlock in multithreaded program |
| CN102819466A (en) * | 2012-06-29 | 2012-12-12 | 华为技术有限公司 | Method and device for processing operating system exceptions |
| CN103399818A (en) * | 2013-08-13 | 2013-11-20 | 中国科学技术大学苏州研究院 | Deadlock detection method in operating system |
| CN103605921A (en) * | 2013-10-28 | 2014-02-26 | 清华大学 | Kernel extension safety access method and device |
| US8875107B2 (en) * | 2009-03-24 | 2014-10-28 | International Business Machines Corporation | Component lock tracing by associating component type parameters with particular lock instances |
| CN104317723A (en) * | 2014-11-14 | 2015-01-28 | 清华大学 | Method and system for tracking running information of drive program |
| CN104603750A (en) * | 2012-08-30 | 2015-05-06 | 微软公司 | Layout and execution of software applications using BPRAM |
| CN104899111A (en) * | 2015-06-09 | 2015-09-09 | 烽火通信科技股份有限公司 | Method and system for dealing with kernel panic of home gateway system |
| CN105159807A (en) * | 2015-09-06 | 2015-12-16 | 浪潮(北京)电子信息产业有限公司 | Method for detecting potential sector errors |
| CN106294137A (en) * | 2016-08-01 | 2017-01-04 | 浪潮(北京)电子信息产业有限公司 | A kind of linux User space spin lock deadlock detection method and system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8832666B2 (en) * | 2009-12-21 | 2014-09-09 | International Business Machines Corporation | Dynamic instrumentation |
-
2018
- 2018-06-25 CN CN201810711766.9A patent/CN108959085B/en active Active
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101403979A (en) * | 2008-10-27 | 2009-04-08 | 成都市华为赛门铁克科技有限公司 | Locking method for self-spinning lock and computer system |
| US8875107B2 (en) * | 2009-03-24 | 2014-10-28 | International Business Machines Corporation | Component lock tracing by associating component type parameters with particular lock instances |
| CN102222015A (en) * | 2010-04-13 | 2011-10-19 | 三星电子（中国）研发中心 | System and method for detecting deadlock in multithreaded program |
| CN102819466A (en) * | 2012-06-29 | 2012-12-12 | 华为技术有限公司 | Method and device for processing operating system exceptions |
| CN104603750A (en) * | 2012-08-30 | 2015-05-06 | 微软公司 | Layout and execution of software applications using BPRAM |
| CN103399818A (en) * | 2013-08-13 | 2013-11-20 | 中国科学技术大学苏州研究院 | Deadlock detection method in operating system |
| CN103605921A (en) * | 2013-10-28 | 2014-02-26 | 清华大学 | Kernel extension safety access method and device |
| CN104317723A (en) * | 2014-11-14 | 2015-01-28 | 清华大学 | Method and system for tracking running information of drive program |
| CN104899111A (en) * | 2015-06-09 | 2015-09-09 | 烽火通信科技股份有限公司 | Method and system for dealing with kernel panic of home gateway system |
| CN105159807A (en) * | 2015-09-06 | 2015-12-16 | 浪潮(北京)电子信息产业有限公司 | Method for detecting potential sector errors |
| CN106294137A (en) * | 2016-08-01 | 2017-01-04 | 浪潮(北京)电子信息产业有限公司 | A kind of linux User space spin lock deadlock detection method and system |
Non-Patent Citations (2)
| Title |
|---|
| BUG: sleeping function called from invalid context at ......（might_sleep函数说明）;hp0773;《https://blog.csdn.net/hp0773/article/details/12658501》;20131012;网页全文第1-2页 * |
| 深入理解各种锁;Fly晴天里Fly;《https://www.jianshu.com/p/5725db8f07dc》;20161224;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108959085A (en) | 2018-12-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9208057B2 (en) | Efficient model checking technique for finding software defects | |
| Abdulla et al. | Verification of programs under the release-acquire semantics | |
| US10943041B2 (en) | Electronic system level parallel simulation method with detection of conflicts of access to a shared memory | |
| US7783470B2 (en) | Verification of concurrent programs having parameterized qualities | |
| Chen et al. | Parametric and sliced causality | |
| US20090265531A1 (en) | Code Evaluation for In-Order Processing | |
| CN101403979A (en) | Locking method for self-spinning lock and computer system | |
| Zhou et al. | Undead: Detecting and preventing deadlocks in production software | |
| US20100131472A1 (en) | Detection and utilzation of inter-module dependencies | |
| Dietrich et al. | Global optimization of fixed-priority real-time systems by RTOS-aware control-flow analysis | |
| KR101979329B1 (en) | Method and apparatus for tracking security vulnerable input data of executable binaries thereof | |
| Reichelt et al. | PeASS: A tool for identifying performance changes at code level | |
| Bai et al. | {DSAC}: Effective Static Analysis of {Sleep-in-Atomic-Context} Bugs in Kernel Modules | |
| CN112925524A (en) | Method and device for detecting unsafe direct memory access in driver | |
| Even-Mendoza et al. | CsmithEdge: more effective compiler testing by handling undefined behaviour less conservatively | |
| CN112306841B (en) | Automatic testing method, device and equipment for track service | |
| CN108959085B (en) | Method and system for detecting sleep error of kernel module in atomic context | |
| CA2518498A1 (en) | Static analysis method for lyee-oriented software | |
| Lourenço et al. | Discovering concurrency errors | |
| Dolz et al. | Enabling semantics to improve detection of data races and misuses of lock‐free data structures | |
| Johansson et al. | Concurrency defect localization in embedded systems using static code analysis: An evaluation | |
| CN117555811B (en) | Embedded software analysis method, device and storage medium based on static symbol execution | |
| CN114153750B (en) | Code checking method and device, code compiling method and electronic equipment | |
| US11900104B2 (en) | Method and system for identifying and removing dead codes from a computer program | |
| Štill et al. | Local nontermination detection for parallel C++ programs |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |