Dataflow Analysis for Concurrent Programs using

Datarace Detection

Ravi Chugh, Jan W. Voung, Ranjit Jhala, Sorin Lerner

LBA Reading GroupMichelle Goodstein

6/5/08

Outline

Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Motivation

Want to apply dataflow analysis to concurrent programs without: Requiring annotations Escape analysis (loss of precision) Custom concurrency analysis Model checking (combinatorial explosion)

Introducing Radar

Scheme for concurrent dataflow analysis Starts with sequential dataflow analysis Race detection creates concurrent analysis Can use already-created race detectors

We’ll see it applied to Relay

Outline

Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Assumptions

For each procedure, either Have access to code Have access to a sound summary

Shared memory is sequentially consistent

Radar’s Key Insights

Adjustability of sequential analysis: Concurrent dataflow facts are a subset of

sequential dataflow facts “Missing facts”

Facts that can be killed by other threads Suppose we have a fact about lvalue l

“At line y, l is not null” Enough to know if another thread can write to l

concurrently “At line z, another thread can write to l”

Radar’s Key Insights Pseudo-Races :

Identify “missing facts”, Remove from sequential analysis

Solution: insert a pseudo-read for location l Ask a race detector: “is there a race at this point for l?”

Yes Another thread can write. Remove fact No No other thread can write. Retain fact.

Producer/Consumer examples follow Non-null dataflow analysis Sequential analysis on left Facts “killed” by concurrency crossed out in red

First example: non-null facts

Producer–Consumer Pseudo-read for px->data at

line PA Consumer thread can

execute line C5 Race! px->data is crossed out at

line PA

Second example: non-null facts

Modified producer/consumer Still race-free, other than

perf_ctr Now, producer

acquires/releases lock twice

Second example: non-null facts

Insert pseudo-read at P5 on px->data

Races with C5 write to cx->data Kills px->data at P5 and where

it propagates At P8, not necessarily true that

px->data is non-null Null pointer dereference! Note: no data races (except on

perf_ctr)

We can detect this!

Outline

Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Sequential Dataflow Analysis

Representation: nodes in CFG Flow function F(n,d,p): facts true after point p

n: node, d: incoming dataflow fact, p: program point lvals(f): lvalues fact f depends on ThreadKill(p,l): computes whether race can

occur on l at program point p

Fadj(n,d,p) = {fF(n,d,p), llvals(f), fThreadKill(p,l)}

Is Radar Sound?

Suppose there is an oracle function O Give a program point p and a location l Returns whether a race is possible

Suppose radar is given a race detector R Radar is sound if O(p,l) implies R(p,l)

If there is a race, radar wil detect it Can also return false positives

Outline

Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Radar Optimizations

Reduce number of times call ThreadKill Handle function calls

Reduce ThreadKill calls

Race detector for cross product of program points and lvalues is expensive

Many program points have similar behavior For each lvalue in a region:

Racy for entire region Not racy for entire region

Compute once for entire region Region Map: points “regions

Incorporating Function Calls

To handle function calls: Introduce a new kind of region: Introprocedural

Summary Region (SumReg) At a particular call site, approximately

summarizes possible regions can pass through To maintain soundness

Suppose there is a transitively reachable path from a callsite cs to a racy region

Summary region must repot that cs is racy

Radar’s Requirements

Race Detection Engine Region Lvalue raciness

Region Map Points Race-equivalent Regions

Summary Region Map Callsites Summary Regions

Outline

Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Relay

Relay Static race detection tool Lockset-based Works bottom up Scales to the linux kernel

Relay

Uses relative lockset analysis: L+, L- :

L+ : locks definitely acquired since function entry point

L- : locks possibly released since function entry point

Relative lockset for exit point of function is stored as summary of function’s behavior Approximates effect of function call on locks

currently held

Radar(Relay) Race Detection Engine

Relay Region Map

Maps program point (g, (L+,L-)) g: function name (L+,L-): relative lockset summary for function g

Summary Region Map Function g being called at the call site cs in function h Computes AllUnlocks(cs) = L- in g Suppose Region is (h, (L+,L-)) Returns (h, (L+ - AllUnlocks(cs),L- AllUnlocks(cs)))

Pseudoreads

Suppose at some program point p fact f holds RegionMap(p): region (g, (L+,L-)) For all lvalues l lvals(f):

Pretend to read l at p with relative lockset (L+,L-) For any other lvalue m which might be aliased…

Intersection of positive locksets is empty report race

Relay with Radar: Implementation First Pass: Run Relay

Computes relative lockset associated with each function

Second Pass: Sequential Analysis Pretend no races exist Collect all the possible queries about races

Third Pass: Run Relay, Adding Pseudo-reads Insert pseudo-access wherever race query exist

Fourth Pass: Adjusted Sequential Analysis At each pseudo-access for l, query race detector If race could occur, kill facts depending on l

Outline

Motivation Overview of Radar Radar(Relay) Radar Formalization Radar Optimizations Evaluation & Results Conclusions

Evaluation

Focus on non-null dataflow analysis Used 4 black boxes to answer race queries

Steensgaard’s pointer analysis If a value is reachable from a global true

Radaralias Region map always returns empty lockset Answers the question of whether any two values alias

Radar Optimistic

Always return false Unsound, and overly precise

Results

Terminology Blob nodes:

Many lvalues on the heap are merged into one node by alias analysis Can lead to false positives when checking null-

dereferences Other work shows hard to account for heap structures Next figure excludes “blob nodes” for pointer

dereferences Non-blob dereferences:

Apache: 52% SSL: 76% Linux: 71%

Results

Results

Consider gap between Seq and Steensgaard Check how much is bridged by Radar

With and without locks

Outline

Motivation Overview of Radar Radar(Relay) Radar Formalization Radar Optimizations Evaluation & Results Conclusions

Conclusions

Radar is Scalable Not tied to particular concurrency models Tunable to desired precision

Radar(Relay) Good precision relative to sequential, steensgaard

Future Work More types of analysis Race detection for other concurrency constructs