Effective Detection of Sleep-in-atomic-context Bugs in the Linux Kernel

Abstract

Atomic context is an execution state of the Linux kernel in which kernel code monopolizes a CPU core. In this state, the Linux kernel may only perform operations that cannot sleep, as otherwise a system hang or crash may occur. We refer to this kind of concurrency bug as a sleep-in-atomic-context (SAC) bug. In practice, SAC bugs are hard to find, as they do not cause problems in all executions. In this article, we propose a practical static approach named DSAC to effectively detect SAC bugs in the Linux kernel. DSAC uses three key techniques: (1) a summary-based analysis to identify the code that may be executed in atomic context, (2) a connection-based alias analysis to identify the set of functions referenced by a function pointer, and (3) a path-check method to filter out repeated reports and false bugs. We evaluate DSAC on Linux 4.17 and find 1,159 SAC bugs. We manually check all the bugs and find that 1,068 bugs are real. We have randomly selected 300 of the real bugs and sent them to kernel developers. 220 of these bugs have been confirmed, and 51 of our patches fixing 115 bugs have been applied.

DCNS

“…Our previous approach DSAC is related to DCNS, but it is different. DSAC [3] is our previous approach of detecting sleep-in-atomic-context (SAC) bugs. DSAC and DCNS both check the Linux kernel and identify the code in atomic context.…”

“…Atomic context analysis is the basis of detecting CNS defects. Our analysis extends that of DSAC, our previous approach for detecting sleep-in-atomic-context (SAC) bugs [3]. DSAC provides a hybrid flow analysis to detect code in atomic context.…”

“…Several previous approaches [3,13,27] can detect sleep-inatomic-context (SAC) bugs, and they perform atomic context analysis. However, they focus on how to accurately find the existence of a path where the code occurs in atomic context.…”

“…Starting from these entry points, the second step uses AtomicAnalysis shown in Figure 2, to identify the code that may be executed in atomic context and mark the non-sleep function calls within this code. Like the analysis of DSAC [3], AtomicAnalysis maintains a lock stack (lock_stack) to store the spinlock state, a path stack (path_stack) to store analyzed basic blocks, and a global flag (g_intr_flag) to indicate whether the code is executed in an interrupt handler. As shown in Figure 2, AtomicAnalysis uses HandleBlock to handle a basic block, HandleCall to handle a function call, and HandleFunc (new as compared to DSAC) to handle the definition of a called function.…”

“…This work includes inter-procedural analysis, but only across direct calls to other functions in the same file. Our previous approach DSAC [3] detects sleep-in-atomic-context bugs in kernel modules, but it does not handle function pointers.…”