Understanding Data Races in the Linux Kernel
summary
States that kernel data races cause silent corruption and security holes and demonstrates tooling: KCSAN (enable CONFIG_KCSAN=y) uses hardware watchpoints plus sampling and prints conflicting read/write addresses, sizes, stack traces and sometimes observed value changes, while TSan uses compiler instrumentation to check every access but is much heavier. Notes KCSAN is probabilistic and misses races (roughly 75% detection reported in experiments), allows sample‑rate tuning, and recommends locks, RCU, atomics and SMP store-release ordering as prevention.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:27Kernel data races matter
- 4:14Kernel concurrency explained
- 8:12Smallest data race example
- 10:43Kernel sync primitives
- 13:34Memory barriers and ordering
- 15:22Static analysis limits
- 16:45TSAN and KCSAN overview
- 18:53KCSAN in action
- 21:28Reading KCSAN reports
- 24:04KCSAN limitations
- 25:48Preventing data races
- 29:05Prevention checklist
- 30:12Key takeaways
- 32:01Q&A
related talks
59mSanitizing the Linux Kernel — On KASAN and other Dynamic Bug-finding Tools
31mRace Conditions - Practical Tools & Techniques for Testing, Preventing, and Debugging C++/C Code
50mBreaking Kernel Address Space Layout Randomization (KASLR) With Intel TSX
38mHow I started chasing speculative type confusion bugs in the kernel and ended up wi...
50mAddressSanitizer/ThreadSanitizer for Linux Kernel
54mCatching Real-time Safety Violations in C++
43mUsing Undocumented CPU Behavior to See Into Kernel Mode and Break KASLR in the Process
23mDealing with Uninitialized Memory in the Kernel