Check the index hasn't changed after writing the cmp entry.
If an interrupt fires while writing the cmp entry we may have a partial entry. Work around this by using atomic_cmpset to set the new index. If it fails we need to set the previous index value and try again as the entry may be in an inconsistent state. This fixes messages similar to the following from syzkaller: bad comp 224 type 2163727253 Reviewed by: tuexen Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D19287
This commit is contained in:
parent
352a2062c9
commit
feb2cc805f
@ -247,11 +247,16 @@ trace_cmp(uint64_t type, uint64_t arg1, uint64_t arg2, uint64_t ret)
|
||||
if (index * 4 + 4 + 1 > info->entries)
|
||||
return (false);
|
||||
|
||||
buf[index * 4 + 1] = type;
|
||||
buf[index * 4 + 2] = arg1;
|
||||
buf[index * 4 + 3] = arg2;
|
||||
buf[index * 4 + 4] = ret;
|
||||
buf[0] = index + 1;
|
||||
while (1) {
|
||||
buf[index * 4 + 1] = type;
|
||||
buf[index * 4 + 2] = arg1;
|
||||
buf[index * 4 + 3] = arg2;
|
||||
buf[index * 4 + 4] = ret;
|
||||
|
||||
if (atomic_cmpset_64(&buf[0], index, index + 1))
|
||||
break;
|
||||
buf[0] = index;
|
||||
}
|
||||
|
||||
return (true);
|
||||
}
|
||||
|
Loading…
x
Reference in New Issue
Block a user