Applying Custom Patterns in Semantic Equality Analysis

Abstract

This paper develops a novel approach to using code change patterns in static analysis of semantic equivalence of large-scale software. In particular, we propose a way to define custom code change patterns, describing changes that do change the semantics but in a safe way, and a graph-based algorithm to efficiently detect occurrences of such patterns between two versions of software. The proposed method allows one to reduce the number of false positive results generated by static code-pattern-based analysis of semantic equivalence by specifying which patterns of changes should be considered semantically equivalent. Our experiments with the Linux kernel show that it is possible to eliminate a substantial number of detected differences with just a small number of patterns, while maintaining a very high scalability of the overall analysis. Furthermore, the proposed concept allows for a possible future combination with automatic inference of patterns, which promises significant improvements in the area of static analysis of semantic equivalence.

A Patterns Used in Experiments

Here, we present details on patterns that we used for our first experiment. For each pattern, we give an example of a real usage of the pattern within the RHEL kernel. Even though our patterns are defined in LLVM IR, we give examples in C, as it is much more readable. The LLVM IR representations of the patterns can be found in the DiffKemp repository. In our experiment, we defined 5 patterns:

• P1: Use READ_ONCE for a memory read

  Usage of the READ_ONCE macro prevents compiler from merging of refetching memory reads. This pattern describes a situation when a simple memory read is replaced by a memory read through the macro. For example:

  $$\begin{aligned} \mathtt {p\! \rightarrow \!cpu} \quad \rightarrow \quad \mathtt {READ\_ONCE(p \!\rightarrow \! cpu)} \end{aligned}$$

  The pattern is parametrised by 3 inputs: (1) the pointer to read from, (2) the field to read, and (3) the type of the pointer.

• P2: Use WRITE_ONCE for a memory write

  The WRITE_ONCE macro is analogical to READ_ONCE, except that it is suited for memory writes. This pattern describes a situation when a simple memory write is replaced by a write through the macro. For example:

  $$\begin{aligned} \mathtt {p\! \rightarrow \!cpu = cpu} \quad \rightarrow \quad \mathtt {WRITE\_ONCE(p\! \rightarrow \!cpu, cpu)} \end{aligned}$$

  This pattern is parametrised by 4 inputs: (1) the pointer and (2) the field to write to, (3) the type of the pointer, and (4) the value to write.

• P3: Use unlikely for a condition

  Usage of the unlikely macro tells the compiler that certain condition will evaluate to true only in a very small number of cases. The compiler can use this information to, e.g., perform a more efficient ordering of instructions. This pattern reflects a situation when the unlikely macro is added to a condition. For example:

  $$\begin{aligned} \mathtt {if (sched\_info\_on())} \quad \rightarrow \quad \mathtt {if (unlikely(sched\_info\_on()))} \end{aligned}$$

  The boolean condition is the single input of the pattern.

• P4: Replace spin_(un)lock by raw_spin_(un)lock

  The Linux kernel provides multiple functions for locking. This pattern describes a situation when usage of spin_lock is replaced by raw_spin_lock. For example:

  

  The same situation may happen with unlocking, hence we would normally need 2 patterns. Thanks to the possibility to specify renaming rules (see Sect. 4.1), our approach allows to handle both locking and unlocking using a single pattern.

• P5: Replace RECLAIM_DISTANCE by node_reclaim_distance

  The RECLAIM_DISTANCE macro and the node_reclaim_distance global variable are two ways of setting a maximum distance between CPU nodes used for load balancing. This pattern describes a situation when the usage of the macro is replaced by the usage of the global variable. Since this is just a simple replacement of one identifier by another, we leave this pattern without an example.