aComment: Mining Annotations from Comments and Code to Detect Interrupt Related Concurrency Bugs

Problem:Detecting OS concurrency bugs is challenging due to the complexity of the OS synchronization, particularly with the presence of the OS specific interrupt context.• The OS specific interrupt context makes OS concurrency extremely complex and it has challenged the OS community for decades

To detect OS concurrency bugs, This paper proposed a new type of annotations– interrupt related annotations.Two of the key techniques that make the above contributions possible are: (1)using a hybrid approach to extract annotations from both code and comments written in natural language to achieve better coverage and accuracy in annotation extraction and bug detection; and (2) automatically propagating annotations to caller functions to improve annotating and bug detection.

Idea: it is feasible to extract interrupt related preconditions and postconditions from both source code and comments written in natural language.

Solution:

1.Annotation Language Design:

This paper design annotations in the following format: @IRQ(Precondition, Postcondition), where Precondition and Postcondition can have one of the 4 values, i.e., 0, 1, X and P. 0: Interrupts are disabled;1: Interrupts are enabled;X: Don’t-care- Interrupts are either disabled or enabled;P: Interrupts are restored to the saved interrupt state. We use (X, P) to indicate functions that restore a saved interrupt state, and all other 6 annotations that contain a value P is not accepted.

 Therefore, although there are 16 possible annotations, only 10 of them are accepted by aComment as shown in following  Table , and the rest of the 6 should not appear in aComment.

@IRQ (Pre, Post)             Meaning
@IRQ (0, 0)               Interrupts are disabled on entry and remain disabled on exit.
@IRQ (0, 1)               Interrupts are disabled on entry but are enabled on exit.
@IRQ (1, 0)               Interrupts are enabled on entry but are disabled on exit.
@IRQ (1, 1)               Interrupts are enabled on entry and remain enabled on exit.
@IRQ (X, X)              Either @IRQ (0, 0) or @IRQ (1, 1)
@IRQ (X, 0)              Don’t-care on entry and interrupts are disabled on exit.
@IRQ (X, 1)              Don’t-care on entry and interrupts are enabled on exit.
@IRQ (0, X)              Interrupts are disabled on entry and don’t-care on exit.
@IRQ (1, X)              Interrupts are enabled on entry and don’t-care on exit.
@IRQ (X, P)              Don’t-care on entry and interrupts are restored to the saved state on exit.

2.Annotation Extraction:

1)Extracting Annotations from Comment:

Comment Extraction: We extracted comment sentences that contain word “interrupt” regardless of cases. Therefore,it is inefficient to manually read all of these comments to extract seed annotations.Therefore, we combine simple program analysis with effective heuristics to extract annotations and manually verified all of the annotations.

Annotation Generation: After extracts the comments that contain the interrupt related preconditions, it needs to decide if the precondition is 0 or 1 and extract the name of the function associated with the annotation.

By identifying the verbs (e.g., “disable” and “enable”) and negation words (e.g., “not”), we can determine the precondition. For example, “disable” is mapped to 0, and a negation word “not” flips the precondition once to 1.

 Given an annotation containing comment, aComment can extract the function name by analyzing the code segment below the comment, e.g., a function definition or a function call statement.

2)Extracting Annotations from Code:  We observed that source code typically contains assertions to indicate that a function must be called with interrupts disabled or enabled. By these dynamic assertions,we use simple static analysis to extract annotations from these assertion macros. We analyze the direct callers of BUG_ON(!irqs_disabled()) and BUG_ON(irqs_disabled()) to see if these functions are intended to be called with interrupt disabled or enabled.For example, Figure 3 shows that function vmi_timer_set_mode calls assertion code

BUG_ON(!irqs_disabled()) as its first statement to indicate that interrupts should have already been disabled before calling vmi_timer_set_mode.So annotation is @IRQ (0, x) .

3.Annotation Propagation

  1)Initialization: We add the seed annotations extracted from comments and assertions to their corresponding functions. Inaddition, we annotate functions that directly disable, enable, or restore interrupts, e.g., local_irq_disable for the Linux kernel,called IRQ functions.

We annotate these IRQ functions with (X, 0) if they disable interrupts, with (X, 1) if they enable interrupts, and with(X, P) if they restore a saved interrupt state. We then find all unannotated functions that do not have any callees, and annotate them with (X, X), meaning that these functions can be called with interrupts disabled or enabled,but the postconditions should be the same as their preconditions.

 2)Propagation: Our propagation analysis starts from the bottom of a call graph to find all functions whose callee functions are all annotated, and automatically infers the annotations for them.After several rounds of propagation from the bottom of the call graphs, all of function update_process_times’s callees are annotated as Figure 4 shows. Therefore, we can infer that the annotation for update_process_times is (0, 0).

4.Annotation Checking and Bug Detection

There are two types of violations, i.e., root function violations and unsatisfiable violations. If a root function’s precondition is not X,it is considered a root function violation, where a root function is a function that does not have a caller (e.g., in the kernel).

If preconditions and postconditions conflict with each other, our tool reports them as unsatisfiable violations. For example,if function A (with annotation (X, 1)) is invoked immediately before function B (with annotation (0, 0)), we know it is not satisfiable because the interrupts are enabled after calling A, but they should be disabled before calling B.

The reported bugs are ranked according to their confidence scores, which are affected by several factors including seed annotation confidence and violation confidence.