1. Effective Data-Race Detection for the Kernel
John Erickson, Madanlal Musuvathi, Sebastian Burckhardt, Kirk Olynyk
Microsoft Research
Effective Data-Race Detection for the Kernel

2. Motivations Need for race detection in Kernel modules
Also must detect race conditions between hardware and Kernel
Decrease run-time overhead from previous approaches
Decrease Bug Fix Time
Solution: DataCollider

3. Kernel Mode Challenges
User Mode
Kernel Mode
Clear synchronization primitives
Complex synchronization primitives and custom implementations
Well defined thread abstractions
Thread context can execute code from various sources
Executes at higher level of concurrency abstraction

4. Previous Approaches Happens-Before Lock-Set Limitations:
Uses event ordering to track possible races
Lock-Set
Checks for violations of locking discipline
Limitations:
Ordering mechanism and synchronization not clear in Kernel
Interrupts and Interrupt Handlers
DMAs

5. Overview of DataCollider
How do they define data race?
Detection technique
Implementation
Before: Static Analysis gathers set of possible races
During: Dynamic Analysis checks set
After: Filter benign races to increase usability
Evaluation

6. Data Race Conflicting memory access by two operations:
Physical memory not disjoint
At least one write
At least one non-synchronization access
Data race exists if two conflicting memory access can be performed simultaneously on a multiprocessor
Definition excludes races that are desirable

7. Detection Technique
Major departure from previously discussed dynamic detection techniques
Ignores synchronizations
Uses hardware supported breakpoints (data and coding) to check for races
Periodic sampling rate detection to control execution frequency

8. Sampling Algorithm
Reduces set of all possible races from all memory access to increase performance
Removes all thread local accesses
Removes all synchronizing instructions
Accesses are sampled using code breakpoints
Set is sampled randomly
Also includes primitives to assign priority
Sampling rate is controlled

9. Conflict Detection Uses HW breakpoint registers (per processor)
Updates atomically
If more registers are needed uses “Repeated Read” technique
If race detected it catches both threads “red handed”
Memory Address Issues

10. Repeated Reads
Repeatedly reads location instead of inserting data breakpoint
Easier Approach but less effective
Limitations:
Unable to determine condition or identity of second thread or device that causes race
Misses cases:
Multiple writes
Reads after Write

11. Variable Delays
Repeated Reads and Data Breakpoints both rely on effective delay values to capture races
Dependent on IRQL of executing thread:
Higher than DISPATCH: no delay
Equal to DISPATCH: random time < 1ms
Less than DISPATCH: <15ms and ensures progress of other threads

12. Pruning Benign Races Necessity for Usability (<10% real errors)
Three Cases Filtered:
Statistics Counters
Safe Flag Updates
Special Variables
Experimentally shown to prune 76% of possible races

13. Evaluation Ran Tests on Windows kernel-modules Two Distinct Reports:
Core kernel executive, class drivers, storage drivers, PnP drivers, etc.
Two Distinct Reports:
Boot Hang
False Benign Data Race

14. Run-Time Overheads Test Set-up:
Host: Intel Core2-Quad 2.4 GHz. 4 GB memory running Windows Server 2008
VM: x86 version of Windows processors and 512 MB memory.

15. Benign Race Pruning
Stress tested kernel with ~1000 code breakpoints / sec
Manually reviewed all Races
Room for improvement of heuristic with Double-check locking and Volatile variables

16. Paper Evaluation

17. Positives Major Improvement in Run-Time overhead
Was tested across a range of kernel-level modules
Size of application and type of synchronization had previously been limiting
Able to reduce false positives using pruning heuristics and thus increase usability
Overall More User Friendly

18. Possible Improvements
Does not discuss specific implementation especially memory requirements of algorithm
Only implemented and tested on Windows
Not a great amount of discussion on how performance may change with OS
No Results on effectiveness of Data Breakpoint vs. Repeated Read methods