| #
1.4 |
|
10-Sep-2020 |
maxv |
kcsan: fix the copyright notices
|
|
Revision tags: bouyer-xenpvh-base2 phil-wifi-20200421 bouyer-xenpvh-base1 phil-wifi-20200411 bouyer-xenpvh-base is-mlppp-base phil-wifi-20200406 ad-namecache-base3 ad-namecache-base2 ad-namecache-base1 ad-namecache-base phil-wifi-20191119
|
|
| #
1.3 |
|
08-Nov-2019 |
maxv |
branches: 1.3.8;
Exclude the PTE space from KCSAN, since there the same VA can point to
different PAs.
|
| #
1.2 |
|
06-Nov-2019 |
maxv |
Change kcsan_md_is_avail() to always return true; I was testing with
interrupts disabled as debugging. Change the delay/sample parameters
to have better fluidity.
|
| #
1.1 |
|
05-Nov-2019 |
maxv |
Add Kernel Concurrency Sanitizer (kCSan) support. This sanitizer allows us
to detect race conditions at runtime. It is a variation of TSan that is
easy to implement and more suited to kernel internals, albeit theoretically
less precise than TSan's happens-before.
We do basically two things:
- On every KCSAN_NACCESSES (=2000) memory accesses, we create a cell
describing the access, and delay the calling CPU (10ms).
- On all memory accesses, we verify if the memory we're reading/writing
is referenced in a cell already.
The combination of the two means that, if for example cpu0 does a read that
is selected and cpu1 does a write at the same address, kCSan will fire,
because cpu1's write collides with cpu0's read cell.
The coverage of the instrumentation is the same as that of kASan. Also, the
code is organized in a way similar to kASan, so it is easy to add support
for more architectures than amd64. kCSan is compatible with KCOV.
Reviewed by Kamil.
|
| #
1.3 |
|
08-Nov-2019 |
maxv |
Exclude the PTE space from KCSAN, since there the same VA can point to
different PAs.
|
| #
1.2 |
|
06-Nov-2019 |
maxv |
Change kcsan_md_is_avail() to always return true; I was testing with
interrupts disabled as debugging. Change the delay/sample parameters
to have better fluidity.
|
| #
1.1 |
|
05-Nov-2019 |
maxv |
Add Kernel Concurrency Sanitizer (kCSan) support. This sanitizer allows us
to detect race conditions at runtime. It is a variation of TSan that is
easy to implement and more suited to kernel internals, albeit theoretically
less precise than TSan's happens-before.
We do basically two things:
- On every KCSAN_NACCESSES (=2000) memory accesses, we create a cell
describing the access, and delay the calling CPU (10ms).
- On all memory accesses, we verify if the memory we're reading/writing
is referenced in a cell already.
The combination of the two means that, if for example cpu0 does a read that
is selected and cpu1 does a write at the same address, kCSan will fire,
because cpu1's write collides with cpu0's read cell.
The coverage of the instrumentation is the same as that of kASan. Also, the
code is organized in a way similar to kASan, so it is easy to add support
for more architectures than amd64. kCSan is compatible with KCOV.
Reviewed by Kamil.
|