OSPP 2022: Add lite-lockdep as a lightweight lock validator · Pull Request !112 · openEuler/kernel

This PR adds lite-lockdep as a lightweight lock validator. Lite-lockdep consists of two modules: lock tracking and deadlock validation.
1）Lock Tracking
Lock tracking inserts hooks at different types of lock initialization, lock acquisition, and release locations (roughly the same as lockdep's insertion locations), thereby continuously recording the held locks of each process. Therefore, when the system enters some abnormal state, complete lock information can be output to assist developers in analysis.
The idea of lock tracking in lite-lockdep is similar to lockdep: each lock instance is mapped to a lock class, and the behavior of a class of locks is tracked to reduce redundant records. There are differences in data structures such as lock classes for lightweight records and subsequent validations. This functionality can be dynamically enabled by the sysctl variable. When a hung task occurs, the complete locking information can be printed, and alarm information is also given for the problem of multiple releases and the problem of use-before-initialization.
2) Deadlock Validation
Deadlock validation in lite-lockdep detects the potential locking dependency inversion problem. The idea of the core algorithm comes from the paper: Low-overhead Deadlock Prediction [1]. This functionality consists of two parts: lock dependency record and cycle detection. Among them, the feature of the lock dependency record is that it not only records the direct lock dependency (such as the locks_after chain in lockdep) but also records the indirect lock dependency formed by the current dependency through the closure transitions. For example: when there is a dependency of A -> B, B -> C, an indirect dependency of A --> C is deduced at the same time. Therefore, in the detection of cycles, the first step is to determine whether there is an inverted dependency, that is, whether a "simple cycle" of A -> B --> A is formed. Only when it is determined that "simple cycles" exist, a complete cycle search needs to be performed, avoiding the great overhead of performing a full search algorithm for each dependency chain.
As long as the required lock dependency information is recorded, the cycle detection can be performed at any time. The lock dependency record and cycle detection in lite-lockdep can be dynamically switched by the sysctl variable. Currently, the variable associated with deadlock detection is set to 1 each time, and a global lock validation is performed. If a potential deadlock is found in the cycle detection, it will output the name of each lock within the cycle, the acquisition address, the pid at the time of acquisition, and the process name. Since it also depends on the notion of dependency inversion, the validation performance of lite-lockdep is consistent with lockdep: it produces no false negatives, and false positives require additional processing.
[1] Cai Y, Meng R, Palsberg J. Low-overhead deadlock prediction[C]//2020 IEEE/ACM 42nd International Conference on Software Engineering (ICSE). IEEE, 2020: 1298-1309.

Special cases: To avoid false positives, the lock dependencies of nested locks and recursive readers defined in the kernel are not recorded. Also, the same special processing as in lockdep is performed in files such as fs/inode.c.

Enable feature: Compile and enable CONFIG_LITE_LOCKDEP to make the following variables available: change the lite_lockdep variable in sysctl to switch the lock tracking function (enabled by default), change the check_reachability variable to switch the lock dependency recording function (check CHECK_LOCK_REACHABILITY when compiling is enabled by default), set the detect_deadlocks variable to 1 to execute deadlock detection.
#### Issue
https://gitee.com/openeuler/kernel/issues/I5R8DS
#### Tests
Tests were carried out for spinlock, mutex, and rwsem respectively: 1. There were no false positives during the kernel startup process; 2. The hang task test was carried out for the lock tracking function, and the correct lock information can be completely printed; 3. The deadlock validation function was tested with The same scenario as in locking-selftest, and it passed the validation of AA deadlock, ABBA deadlock, ABBCCA deadlock, ABBCCDDA deadlock, ABCDBDDA deadlock, ABCDBCDA deadlock, and multiple releases.
#### Known Problems
1. Currently only mutex, spinlock, and rwsem locks are supported, rwlock, seqcount, etc. are not covered.
#### Default Config Change
NA

GVPopenEuler/kernel

搜索帮助

GVP openEuler/kernel