This blog post is about the bugs and FPs I found for the case which checks for locks around possibly blocking functions.
The rule is :
“To avoid deadlock, do not call blocking functions with interrupts disabled or a spinlock held.” Implementing this checker requires knowing the set of functions that may block, the set of functions that disable interrupts, and the set of functions that
To identify blocking functions, two kinds of functions are considered as the starting point. First, we observe that basic memory allocation functions, such as the kernel function kmalloc, often take as argument the constant GFP_KERNEL when they are allowed to block until a page becomes available. Thus, a function that contains a call with GFP_KERNEL as an argument may block.
Second, that blocking is directly caused by calling the function schedule.
BlockIntr checks for the case where a blocking function is called while interrupts are disabled. However, blocking with interrupts turned off is not necessarily a fault, and indeed core Linux scheduling functions, such as interruptible_sleep_on, call schedule with interrupts turned off. Taken this issue into account when checking for false positives. Analogously, we consider the case where a blocking function is called while holding a spinlock, which is always a fault.
Not much cases are there in the reports related to this case.
What did I found?
Most out of the TODOs were Bugs.
For some cases comments in the code confirmed that it is a bug and it is need to be rewritten properly.
Some were intentional FPs.
Some patches are lined up for this case too.