DRDDR: a lightweight method to detect data races in Linux kernel

Jiang, Yunyun; Yang, Yi; Xiao, Tian; Sheng, Tianwei; Chen, Wenguang

doi:10.1007/s11227-016-1691-1

Cited by 6 publications

(4 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Secondly, we analyze driver concurrency at function-level granularity, which is a trade off between accuracy and performance. Many previous approaches (such as [20], [21]) analyze driver concurrency at instruction-level granularity, to achieve good accuracy and reproduce real data races, but they often introduce much overhead.…”

Section: A Threats To Validitymentioning

confidence: 99%

“…Sampling-based approaches [5], [7], [14], [20], [21] monitor variable accesses at intervals instead of tracking all variable accesses, and thus they can achieve better performance than happens-before-based approaches. For example, LiteRace [14] is an effective sampling-based approach to detect data races in user-level applications.…”

Section: A Dynamic Analysismentioning

confidence: 99%

“…They are based on sampling or lockset analysis. The effectiveness of the sampling-based approaches [20], [21] heavily relies on the sampling frequency. These approaches * Jia-Ju Bai is the corresponding author.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Detecting Data Races Caused by Inconsistent Lock Protection in Device Drivers

Chen

Bai

Jiang

et al. 2019

2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER)

View full text Add to dashboard Cite

Data races are often hard to detect in device drivers, due to the non-determinism of concurrent execution. According to our study of Linux driver patches that fix data races, more than 38% of patches involve a pattern that we call inconsistent lock protection. Specifically, if a variable is accessed within two concurrently executed functions, the sets of locks held around each access are disjoint, at least one of the locksets is non-empty, and at least one of the involved accesses is a write, then a data race may occur. In this paper, we present a runtime analysis approach, named DILP, to detect data races caused by inconsistent lock protection in device drivers. By monitoring driver execution, DILP collects the information about runtime variable accesses and executed functions. Then after driver execution, DILP analyzes the collected information to detect and report data races caused by inconsistent lock protection. We evaluate DILP on 12 device drivers in Linux 4.16.9, and find 25 real data races.

show abstract

Section: A Threats To Validitymentioning

confidence: 99%

Section: A Dynamic Analysismentioning

confidence: 99%

See 1 more Smart Citation

Detecting Data Races Caused by Inconsistent Lock Protection in Device Drivers

Chen

Bai

Jiang

et al. 2019

2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER)

View full text Add to dashboard Cite

show abstract

“…Some approaches sample and examine a very small portion of the entire memory accesses, sacrificing accuracy with increased false negatives [5], [32], [33]. Other approaches exploit the support from custom hardware [34], [35] or commodity hardware [36], [37] like transactional memory [38]. Another approaches include parallelizing detection efforts [39], removing unnecessary information about access orderings [40], and combining the lockset algorithm with happens-before reasoning [41].…”

Section: Analysis Overheadmentioning

confidence: 99%

Software Analysis Techniques for Detecting Data Race

Kang

2017

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

SUMMARYData races are a multithreading bug. They occur when at least two concurrent threads access a shared variable, and at least one access is a write, and the shared variable is not explicitly protected from simultaneous accesses of the threads. Data races are well-known to be hard to debug, mainly because the effect of the conflicting accesses depends on the interleaving of the thread executions. Hence there have been a multitude of research efforts on detecting data races through sophisticated techniques of software analysis by automatically analyzing the behavior of computer programs. Software analysis techniques can be categorized according to the time they are applied: static or dynamic. Static techniques derive program information, such as invariants or program correctness, before runtime from source code, while dynamic techniques examine the behavior at runtime. In this paper, we survey data race detection techniques in each of these two approaches.

show abstract