Detecting Data Races Caused by Inconsistent Lock Protection in Device Drivers

Abstract

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.

Refactoring traces to identify concurrency improvements

“…Whereas Rehype focuses on performance and is purely dynamic-analysis-based, much of the existing work on concurrency analysis focuses on detecting concurrency-based bugs such as race conditions [1,2,7], deadlocks [1], and more-general thread-safety violations [3,6]. Most approaches are either based on static analysis [7], potentially with subsequent confirmation via dynamic analysis [14] or a hybrid approach [1], or use dynamic analysis such as execution-replay [10] or execution-modification [6] (such as injected delays) to trigger bugs.…”

“…While there are some primarily dynamic analysis-based approaches (e.g. Chen et al [2]), these also focus on bug detection. We hypothesise that concurrency analysis research currently focuses on bug detection for two reasons: 1) there is a clear, immediate, and measurable benefit -every additional bug detected is valuable; and 2) concurrency performance analysis is predicated on a low-overhead tracer that avoids distorting concurrent behaviour (whereas bug detection may use higher overhead dynamic analysis tools).…”