data_race(9)

🎀 NAME 🎀

okay so bestie, this is the data_race(9) page from the Kernel API Manual, and it's literally about marking an expression as containing intentional data races 👑✨

data_race — mark an expression as containing intentional data races. periodt 💅

---

✨ SYNOPSIS ✨

data_race (expr );

---

💅 ARGUMENTS 💅

• expr — bestie, the original page just says -- undescribed -- here, so that's literally all the detail we have 🙈🫠

---

🦋 DESCRIPTION 🦋

This data_race macro is your forgiving bestie for situations where data races should be forgiven 💖 One example is diagnostic code that accesses shared variables but is not a part of the core synchronization design. it's giving "yes I'm touching the shared variable, no I'm not part of the locking situation" 😭

So picture this: accesses to a given variable are protected by a lock, except for diagnostic code. In that case, the accesses under the lock should be plain C-language accesses, and those in the diagnostic code should use data_race ✨ This way, KCSAN will complain if buggy lockless accesses to that variable are introduced, even if the buggy accesses are protected by READ_ONCE or WRITE_ONCE 👀🔥

🚨 real talk: this macro does not affect normal code generation, but it is a hint to tooling that data races here are to be ignored 🫶

If the access must be atomic and KCSAN should ignore the access, use both data_race and READ_ONCE, for example, data_race(READ_ONCE(x)) 💜

---

🌈 SEE ALSO 🌈

• Kernel file ./tools/virtio/linux/compiler.h — go read that, iykyk 👀📚

---

xoxo, this has been data_race(9) from ./tools/virtio/linux, October 2026 💖✨