-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathconflict_sample.txt
222 lines (222 loc) · 3.95 KB
/
conflict_sample.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
# In finaliseCapUnexposed, cap types handled by finaliseCapTryExposed
# are distinct from the types handled by finaliseCapUnexposed
conflict
0xf00152ec
0xf00149f8
0xf00152b0
0xf001541c
conflict
0xf00152ec
0xf0014a4c
0xf00152b0
0xf001541c
conflict
0xf00152ec
0xf0014a64
0xf00152b0
0xf001541c
conflict
0xf00152ec
0xf0014a28
0xf00152b0
0xf001541c
# We don't need to reschedule after activating the current thread
conflict
0xf0010db4
0xf0016ea0
0xf0016ea0
0xf0016ee4
# We know caps in installed in the TCB are not final
conflict
0xf0012f10
0xf0015c90
0xf0015c90
0xf001685c
# This ensures that the cteDelete in decodeTCBInvocation deletes a
# cspace
consistent
0xf0015b14
0xf001531c
0xf0015c90
0xf001685c
# This ensures that the cteDelete in decodeTCBInvocation deletes a
# vspace
consistent
0xf0015b84
0xf0013fcc
0xf0015c90
0xf001685c
conflict
0xf0013fcc
0xf00140e8
0xf001685c
0xf0015b84
conflict
0xf0013fcc
0xf0013fe4
0xf001685c
0xf0015b84
# This ensures that the cteDelete in decodeTCBInvocation deletes a
# frame
consistent
0xf0015bcc
0xf00140f4
0xf001685c
0xf0015b84
# doReplyTransfer's call to cteDeleteOne deletes a reply cap.
conflict
0xf0014fe0
0xf00149f8
0xf0014fe0
0xf00151dc
conflict
0xf0014fe0
0xf00149e0
0xf0014fe0
0xf00151dc
conflict
0xf0014fe0
0xf0014a28
0xf0014fe0
0xf00151dc
conflict
0xf0014fe0
0xf0014a64
0xf0014fe0
0xf00151dc
consistent
0xf0012ff0
0xf0012a90
0xf0014fe0
0xf00151dc
# deleteCallerCap only deletes a reply cap. - eliminate
# finaliseCapTryExposed
conflict
0xf0017050
0xf00149f8
0xf0017050
0xf001736c
conflict
0xf0017050
0xf00149e0
0xf0017050
0xf001736c
conflict
0xf0017050
0xf0014a28
0xf0017050
0xf001736c
conflict
0xf0017050
0xf0014a64
0xf0017050
0xf001736c
# Same as above, but for sameRegionAs
consistent
0xf0012ff0
0xf0012a90
0xf0017050
0xf001736c
# success of lookupTargetSlot in getReceiveSlots concurs with
# success of getReceiveSlots (inlined within doIPCTransfer)
consistent
0xf0011534
0xf0013804
0xf00132f8
0xf0013814
# success of lookupTargetSlot in decodeCNodeInvocation concurs with
# success of decodeCNodeInvocation
consistent
0xf0011534
0xf0016908
0xf0016870
0xf0016e90
consistent
0xf0011534
0xf00116cc
0xf0016870
0xf0016e90
# success of lookupCapAndSlot in handleInvocation concurs with success
# of resolveAddressBits.
consistent
0xf0018e98
0xf0011534
0xf0018e48
0xf00190a0
# success of lookupSlotForCNodeOp in concurs with success of
# resolveAddressBits.
consistent
0xf00116cc
0xf0011534
0xf00115e0
0xf0011714
# success of lookupExtraCaps in concurs with success of
# resolveAddressBits.
consistent
0xf001273c
0xf0011534
0xf00125d0
0xf0012788
# Only one receive slot is ever used in each direction (at most 2 for
# a call or reply/wait)
times
2
0xf001354c
# Caps only transfer if all lookups were successful.
consistent
0xf001273c
0xf00134e0
0xf00132f8
0xf0013814
# In a ReplyWait, the wait will not need to delete the replycap. We do this
# by making handleWait consistent with cteDeleteOne's short-circuit case,
# which you might think is bad because a Wait alone could be the worst case,
# but isn't actually bad, because if a Wait had a worst case of x, a
# ReplyWait would be even worse.
consistent
0xf0014c20
0xf0017050
0xf0017050
0xf001736c
# success of lookupCap in handleWait concurs with
# success of getReceiveSlots
conflict
0xf0011554
0xf001709c
0xf0017050
0xf001736c
conflict
0xf00114f8
0xf001709c
0xf0017050
0xf001736c
# sendFaultIPC (inlined into handleFault) does not cause a doNormalTransfer
consistent
0xf0016f20
0xf001370c
0xf0016f20
0xf001704c
consistent
0xf0013704
0xf001370c
0xf0016f20
0xf001704c
conflict
0xf0013714
0xf001370c
0xf0016f20
0xf001704c
# In the context of handleReply, possibleSwitchTo would never call
# rescheduleRequired, as we would not have previously scheduled a new
# thread.
conflict
0xf00151e8
0xf0010e88
0xf00151e8
0xf0015228
# In any kernel execution, at most three threads will ever be enqueued onto
# the scheduler's run queue: the currently running thread, a thread who
# we're replying to, and the thread who we just waited for.
times
3
0xf0010d34