Tolerating Asymmetric Data Races with Unintrusive...

Pacman:Tolerating Asymmetric Data Races

with Unintrusive HardwareShanxiang Qi, Norimasa Otsuki*, Lois Orosa Nogueira**, Abdullah Muzahid and

Josep Torrellas

Department of Computer ScienceUniversity of Illinois at Urbana-Champaign

http://iacoma.cs.uiuc.edu

*Renesas Electronics Corporation, Japan**Universidade de Santiago de Compostela, Spain

1

University

of Illinoishttp://iacoma.cs.uiuc.edu/

Friday, March 9, 12



Pacman: Tolerating Asymmetric Races University

of Illinoishttp://iacoma.cs.uiuc.edu/Shanxiang Qi

Data Race

✤ Two threads access same variable without intervening sync

✤ At least one is write

✤ Data races are very common; some are more harmful than others

✤ Must focus on removing the harmful ones --> those in bug reports

Data Races

HarmfulBugs

2

T1

rd x

T2

wr x

Friday, March 9, 12



Asymmetric Data Race

T1

Lockif(pointer !=NULL){

pointer->x = X1;pointer->y = X2;}

Unlock

T2

pointer = NULL;

✤ Data race where at least one of the threads is inside a critical section

3

Safe

Thre

adUns

afe

Thre

ad

Friday, March 9, 12



Importance✤ Asymmetric data races are likely harmful

✤ The data being corrupted is data protected in a critical section

✤ Asymmetric data races are common

✤ 20% of reported harmful data races are asymmetric

✤ A Microsoft report confirmed this problem

✤ Third party drivers

✤ Legacy single-threaded libraries

4

Friday, March 9, 12



Contributions✤ Quantitative evidence to show asymmetric data races are harmful and

common

✤ Pacman: a scheme to prevent asymmetric races in production runs

✤ Unintrusive hardware support

✤ Negligible execution overhead

✤ No changes to the software

✤ Discovered two unreported asymmetric race bugs

5

Friday, March 9, 12



Outline

✤ Motivation

✤ Study of Asymmetric Races

✤ Pacman Design

✤ Evaluation

✤ Conclusions

6

Friday, March 9, 12



Study of Harmful Races

✤ Collected 50 races from open source bug libraries and reports

➡ servers

➡ desktop apps

➡ OS & libraries

Apps. Description

Apache Web Server

MySQL Database sever

Mozilla Browser

Pbzip2 Parallel bzip2

Redhat glibc libraryJAVA SDK

Windows Kernellibcprops C library

Ser

ver

Desktop

OS

&

libra

ries

7

Friday, March 9, 12



Asymmetric Data Races are Common

✤ 10 out of 50 harmful data races are asymmetric races

Application Source OutcomeApache Bug# 1507 ExceptionMySQL Bug# 48930 System hangs

Mozilla-JS Bug# 622691 Incorrect resultMozilla-XPConnect Bug# 557586 Segmentation faultMozilla-Video/Audio Bug# 639721 Incorrect result

Pbzip2 Report Segmentation faultWindows Report Incorrect resultWindows Report Incorrect resultWindows Report Incorrect resultLibcprops Report Incorrect result

8

Friday, March 9, 12



Outline

✤ Motivation


✤ Pacman Design

✤ Evaluation

✤ Conclusions

9

Friday, March 9, 12



✤ Preventing versus detecting bugs✤ All users benefit, not just programmers✤ No need to wait for lengthy bug-fixing cycles

✤ No training phase✤ Hard to define “correct” run

10

Design Philosophy

✤ Goal: Prevent asymmetric data races in production runs with no training.

Friday, March 9, 12



Main Idea✤ Leverage hardware cache coherence to temporarily protect the variables

being accessed in a critical section

11

T1 T2Acquire(L)

Release(L)

wr x

rd x

wr xNac

k

Friday, March 9, 12



Allowed Interleaving Accesses12

T1

Acquire(L)

Release(L)

rd x

T2

wr x

wr xrd x

Friday, March 9, 12



Allowed Interleaving Accesses13

T1

Acquire(L)

Release(L)

wr x

T2

rd x

rd xwr x

Friday, March 9, 12



Overall System

✤ Pacman module: watches the traffic✤ Associated with the bus controller or directory controller✤ Summarizes addresses in hardware signatures

14

$

P $

P $

P $

P

Memory Pacman Module

Network

PacmanModule

Friday, March 9, 12



Hardware Signature

✤ Bloom filter that accumulates addresses ✤ Summarizes the footprint of a piece of code (critical section)✤ Inexpensive operations on groups of addresses

15

Friday, March 9, 12



Example

✤ Thread enters a critical section to be protected✤ HW informs the Pacman module✤ Pacman module allocates a signature + inserts L

16

T1 T2

Acquire(L)

Release(L)

wr xrd x/ wrx

PID SignatureT1 Sig(L)

Pacman Module

Friday, March 9, 12



✤ For every cache miss/coherence transaction from the safe thread ✤ HW adds address to signature

T1 T2

Acquire(L)

Release(L)

wr xrd x/ wrx

PID SignatureT1 Sig(L, )x

17

Example

Pacman Module

Friday, March 9, 12



✤ Every cache miss/coherence transaction from unsafe thread ✤ HW checks the signature✤ If match, bounce it (the processor will retry)

T1 T2

Acquire(L)

Release(L)

wr xrd x/ wrx

PID SignatureT1 Sig(L, x)

Nack

rd x/ wrx

18

Example

Pacman Module

Friday, March 9, 12



✤ Release the lock✤ HW deallocates the entry

T1 T2

Acquire(L)

Release(L)

wr x

PID SignatureT1 Sig(L, x)

19

Example

rd x/ wrx

Pacman Module

Friday, March 9, 12



Issues✤ Cache effects

✤ Pacman Module does not see the accesses intercepted by the caches

✤ Deadlocks

✤ Two or more processors Nack each other

20

Friday, March 9, 12



Cache State Before Entering the Critical Section

✤ Data accessed in the critical section may already be cached in the safe processor in a “silent” state

21

T1

Acquire(L)

x: D in cache

wr x

Release(L)

T2

rd x

Write-back, insert in signature and Nack requester

T1 T2

Acquire(L)rd x

Release(L)wr x

x: S in cache

Invalidate, insert in signatureand Nack requester

Friday, March 9, 12



Cache Displacements During the Critical Section (CS)

✤ Data displaced from the cache while executing a monitored CS✤ May have been silently accessed✤ Must be conservatively placed in the signature

✤ If dirty line --> line naturally written back✤ If clean line --> issue a notification signal

✤ Inside a monitored CS, put the cache in Notification mode

22

Acquire(L)

CacheRelease(L)

...

Network

Friday, March 9, 12



Deadlocks23

✤ Occurs in race bugs where all the threads synchronize

✤ Cross-thread stall cycle: no thread makes progress

Friday, March 9, 12



✤ Add one extra field in each entry of the Pacman Module

24

Breaking the Deadlock

PID Stall_index Signature

✤ Detect a cycle in hardware immediately

✤ Break the cycle right away

✤ Allow one of the threads to perform one access without Nack

✤ May break the atomicity of one of the critical sections

i j

j i

Ti Tj

Friday, March 9, 12



Advantages of Pacman✤ Since goal is to prevent races:

✤ Ok to have false positives (as long as little slowdown)

✤ Simpler hardware is enough (no epoch IDs, etc)

✤ No software changes:

✤ Synch primitives changed but hidden in library calls

✤ Usable as primitive for security and debugging

25

Friday, March 9, 12



Limitations✤ Requires identifying critical section entry and exit points

✤ Not designed for certain unusual types of critical sections

✤ Very large critical sections

✤ Spinning on flag inside a critical section

26

Friday, March 9, 12



Outline

✤ Motivation


✤ Pacman Design

✤ Evaluation

✤ Conclusions

27

Friday, March 9, 12



Evaluation Setup✤ Use Pin instrumentation + SESC simulator

✤ Simulate CMP with 4 or 8 processors, snoopy-based MESI

✤ Evaluate on SPLASH-2, PARSEC, Sphinx3 and Apache

✤ Find two real bugs

28

Friday, March 9, 12



Characterizing Critical Sections

✤ Critical sections are small✤ Critical sections account for only 0.24% of total dynamic instructions

29

0

30

60

90

120

SPLASH-2 Kernels

SPLASH-2 AppsPARSEC Kernels

PARSEC AppsApache&Sphinx3

Average

#Dynamic Insts per Critical Section(Avg)

Friday, March 9, 12



✤ Sources of execution overhead in Pacman✤ Processes are Nacked and have to retry✤ Extra traffic: notifications and retries

30

Execution Time Overhead of Pacman

✤ Pacman performance overhead is negligible✤ Very few false positives

0"

0.05"

0.1"

0.15"

0.2"

0.25"

0.3"

0.35"

0.4"

0.45"

1" 4" 8"

Execu&

on)Tim

e)Overhead)(%

))

Number)of)Threads)

Average"of"the"applica8ons"

Friday, March 9, 12



Unreported Bug from FMM31

T1 T2

pb = b->parent

Lock

pb->subtree_cost += b->subtree_cost;

Unlock

pb->interaction_sync +=1; b->interaction_sync =0;

pb->subtree_cost += b->subtree_cost;

Friday, March 9, 12



Also in the Paper✤ Implementation of Pacman

✤ Virtualization

✤ Extensions for multithreaded processors

✤ Pacman Module for directory protocol

32

Friday, March 9, 12



Software Schemes to Tolerate Asymmetric Data Race

✤ ToleRace [PPOPP’09], ISOLATOR [ASPLOS’09]

✤ When safe thread enters critical section

✤ Software makes copy of the data and redirects safe thread to access the copy

✤ May also change the page protections

✤ Limitations

✤ Significant slowdown

✤ Requires significant software changes

✤ May induce inconsistent execution or new deadlocks

33

Friday, March 9, 12



Conclusion✤ Quantitative study of asymmetric data races

✤ Pacman: hardware scheme to prevent asymmetric data races in production runs

✤ Unintrusive hardware support

✤ Negligible execution overhead

✤ No changes to the software

✤ Discovered two unreported asymmetric race bugs

34

Friday, March 9, 12



Thank You!

35

Friday, March 9, 12

Pacman:Tolerating Asymmetric Data Races

with Unintrusive HardwareShanxiang Qi, Norimasa Otsuki*, Lois Orosa Nogueira**, Abdullah Muzahid and

Josep Torrellas

Department of Computer ScienceUniversity of Illinois at Urbana-Champaign


*Renesas Electronics Corporation, Japan**Universidade de Santiago de Compostela, Spain

36

University

of Illinoishttp://iacoma.cs.uiuc.edu/

Friday, March 9, 12





37

Backup Slide

Friday, March 9, 12



Evaluation

University


38

Friday, March 9, 12



Detecting vs. Tolerating Detecting data

raceTolerating data

race

Program users

HW Support

Correctness (program)

False positive(races&bugs)

39

Friday, March 9, 12



Basic Protocol

SigTable

Pid Signature NestingLevel

40

Friday, March 9, 12



PID Signature Stall_index Lock_acquire?

0

1

Index

T0

T1

Sig(L0,g0) 1 1

Sig(L1) 0 0

Sig(L0)

41

Breaking the Deadlock

Friday, March 9, 12

Date post:	01-Oct-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Tolerating Asymmetric Data Races with Unintrusive...

Documents