| /* SPDX-License-Identifier: GPL-2.0 */ | |
| #ifndef LINUX_COMPILER_H | |
| #define LINUX_COMPILER_H | |
| #include "../../../include/linux/compiler_types.h" | |
| #define WRITE_ONCE(var, val) \ | |
| (*((volatile typeof(val) *)(&(var))) = (val)) | |
| #define READ_ONCE(var) (*((volatile typeof(var) *)(&(var)))) | |
| #define __aligned(x) __attribute((__aligned__(x))) | |
| /** | |
| * data_race - mark an expression as containing intentional data races | |
| * | |
| * This data_race() macro is useful for situations in which data races | |
| * should be forgiven. One example is diagnostic code that accesses | |
| * shared variables but is not a part of the core synchronization design. | |
| * For example, if accesses to a given variable are protected by a lock, | |
| * except for diagnostic code, then 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(). | |
| * | |
| * This macro *does not* affect normal code generation, but 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)). | |
| */ | |
| #define data_race(expr) \ | |
| ({ \ | |
| __auto_type __v = (expr); \ | |
| __v; \ | |
| }) | |
| #endif |